Checklist de première utilisation

De la commande au premier build Xcode

Ce guide suit l’ordre réel de livraison : confirmez d’abord Debug M4, la durée et le nœud, vérifiez ensuite la confirmation d’accès, établissez les connexions SSH et VNC, puis validez la livraison avec une archive téléchargeable.

Louer un Mac dans le cloud Vérifier les tarifs

Configuration disponible: Debug M4
Tarif d’entrée: $19.5/jour
Type de livraison: Nœud physique dédié

Espace de contrôle du premier build Réserver la configuration

Ticket DM-START

Première tâche d’archivage

À exécuter

Configuration: Mac Mini M4
16GB RAM · 256GB SSD
Catalogue des nœuds: Singapour, Japon (Tokyo), Corée du Sud (Séoul), Hong Kong, ouest des États-Unis
Accès: Clé SSH · identifiants VNC
Livrable de validation: Archive.xcarchive

01Vérifier la commandeConfiguration, durée, région et montant en USD
02Vérifier l’accèsEmpreinte, clé, session graphique et reconnexion
03Lancer le buildVérification de la toolchain, archivage et téléchargement du livrable

Vérifications préalables

Préparez les six éléments nécessaires

Avant de commander, vérifiez ensemble la configuration, les éléments d’accès et les options supplémentaires afin de limiter les échanges ultérieurs. L’état réellement disponible est indiqué en temps réel dans la console.

01 Confirmer la configuration de base

L’offre actuellement disponible est Debug M4 : Mac Mini M4, 16GB RAM et 256GB SSD. Chaque commande correspond à un nœud physique dédié, et non à une machine virtuelle.

02 Choisir la durée

Selon la durée de la tâche, choisissez une formule à la journée, à la semaine, au mois ou au trimestre. Les tarifs de base sont respectivement $19.5,$52.8,$97.7 et $265.7.

03 Choisir le nœud

Le catalogue comprend cinq nœuds : Singapour, Japon (Tokyo), Corée du Sud (Séoul), Hong Kong et ouest des États-Unis. Privilégiez la région proche de votre dépôt de code, de votre stockage d’artefacts ou de vos principaux opérateurs.

04 Préparer la clé publique SSH

Utilisez une paire de clés dédiée et conservez la clé privée localement. Avant d’envoyer la clé publique, vérifiez qu’elle est complète ; n’inscrivez jamais la clé privée dans les notes de commande, un dépôt ou un ticket.

05 Évaluer le besoin de VNC

Pour un build en ligne de commande, commencez par SSH. Activez ensuite une session VNC si vous avez besoin d’une interface graphique, d’un contrôle de l’affichage ou d’utiliser Xcode de manière interactive.

06 Vérifier les options supplémentaires

Pour les dépendances volumineuses, les modèles ou les ressources, choisissez +1TB SSD ou +2TB SSD. Pour les tâches multi-machines, sélectionnez Thunderbolt 5 en parallèle pour chaque machine.

Processus de commande

Configurez et payez avec une seule checklist

La console récapitule la configuration de base, la période, le nœud et les options selon vos choix. Avant le paiement, fiez-vous au montant final affiché en USD, sans estimation personnelle ni devis oral.

01
Sélectionner Debug M4

Vérifiez que la puce est bien M4, que la mémoire est de 16GB et que le stockage de base est de 256GB SSD, sans ajouter de configuration hors catalogue.
02
Choisir la région et la durée

Sélectionnez une région parmi les cinq nœuds disponibles, puis choisissez le jour, la semaine, le mois ou le trimestre selon la durée de votre tâche.
03
Ajouter les extensions nécessaires

Ne payez que le stockage ou la connexion Thunderbolt 5 en parallèle nécessaires à votre workflow, puis vérifiez l’unité de facturation.
04
Vérifier et payer

Contrôlez un à un la région, la période, les options et le montant dû en USD, puis utilisez la passerelle de paiement disponible.

Confirmation de livraison

Vérifiez ces six champs un par un

Ne vous connectez pas dès que vous voyez l’adresse de l’hôte. Vérifiez d’abord la région, l’identité, l’empreinte et les limites de la durée, puis stockez les identifiants sensibles dans un emplacement sécurisé approuvé par votre équipe.

Champs de confirmation de livraison DebugMac et méthode de vérification
Champ de confirmation	Éléments à vérifier	Que faire en cas d’anomalie
Région du nœud	Elle doit correspondre à l’une des régions sélectionnées dans la commande : Singapour, Japon (Tokyo), Corée du Sud (Séoul), Hong Kong ou ouest des États-Unis.	Interrompez la première connexion, puis ouvrez un ticket dans la console avec l’identifiant de commande.
Adresse de l’hôte	Vérifiez que le format est complet et qu’aucun espace, signe de ponctuation ou saut de ligne n’a été copié.	Effectuez d’abord une résolution et un contrôle du port ; ne devinez pas l’adresse à répétition.
Nom d’utilisateur	Utilisez le nom d’utilisateur système indiqué dans la confirmation, sans le remplacer par celui de votre ordinateur local.	Conservez le message d’erreur original du terminal, rendez-le non identifiable, puis envoyez-le.
Empreinte de l’hôte	Lors de la première connexion SSH, l’empreinte affichée doit correspondre caractère par caractère à celle de la confirmation.	En cas de différence, interrompez immédiatement et ne saisissez pas le caractère de confirmation.
État d’émission des accès	La clé publique SSH et les identifiants VNC doivent apparaître comme émis ou prêts à l’emploi.	Attendez la mise à jour de l’état ou vérifiez-le via un ticket dans la console ; ne créez pas une nouvelle commande.
Date limite de la durée	Notez le fuseau horaire et l’heure limite afin de planifier les builds, exports, renouvellements et retraits d’accès.	Si la période ne correspond pas, vérifiez d’abord le détail de la commande, puis ouvrez un ticket de facturation.

Première connexion

SSH vérifie l’environnement, VNC la session graphique

Ces deux accès servent à des contrôles différents. SSH vérifie l’identité, l’architecture, le stockage et la toolchain ; VNC vérifie l’affichage, le clavier et la reconnexion après coupure.

SSH

Première connexion SSH

Insérez l’adresse de l’hôte et le nom d’utilisateur figurant dans la confirmation de livraison dans la commande de connexion.
Comparez caractère par caractère l’empreinte affichée dans le terminal avec celle de la confirmation.
Indiquez explicitement la clé privée utilisée pour cette commande afin d’éviter que le client sélectionne la mauvaise identité.
Exécutez uname -m; le résultat attendu est arm64.
Exécutez df -h pour vérifier la capacité du disque système et du stockage supplémentaire.
Exécutez date pour vérifier l’heure système et le fuseau horaire des journaux de tâche.

Critères de validation

L’empreinte correspond, la connexion par clé fonctionne, l’architecture est arm64 et la capacité disque ainsi que l’heure système correspondent à la commande et au workflow.

VNC

Première session VNC

Établissez une session sécurisée avec les informations de connexion de la confirmation de livraison ; ne réutilisez pas les identifiants d’une autre commande.
Vérifiez que la résolution, le facteur d’échelle et le rendu des couleurs conviennent à la tâche.
Testez les claviers chinois et anglais, les touches de fonction, les touches modificatrices et les raccourcis.
Ouvrez Xcode et vérifiez que l’interface répond correctement aux entrées.
Déconnectez volontairement la session une fois, reconnectez-vous, puis vérifiez que l’état de la tâche est conservé.
À la fin du test, fermez les applications graphiques inutiles afin de limiter les ressources consommées.

Critères de validation

La session graphique s’établit de manière sécurisée, l’affichage et la disposition du clavier sont corrects et la reconnexion après une coupure volontaire fonctionne avec les informations de la confirmation.

Console d’exécution des commandes

Remplacez les valeurs d’exemple avant de copier une commande

L’hôte, le nom d’utilisateur, le chemin de clé, le dépôt et le nom du projet utilisés dans les exemples sont fictifs. N’inscrivez pas de véritables identifiants dans des documents partagés, des journaux de build ou des dépôts publics.

Contrôles du premier build · zsh

Établir la connexion SSH

$ ssh -i ~/.ssh/<KEY_FILE> <USER>@<HOST>

Confirmer l’architecture Apple Silicon

$ uname -m
arm64

Vérifier la toolchain Xcode

$ xcodebuild -version
Xcode <VERSION>
Build version <BUILD_VERSION>

Lancer l’archivage

$ xcodebuild -workspace <APP>.xcworkspace \
  -scheme <SCHEME> \
  -configuration Release \
  -archivePath build/<APP>.xcarchive \
  archive
** ARCHIVE SUCCEEDED **

Exécuter le workflow fastlane

$ bundle exec fastlane <LANE>
[fastlane] archive: build/<APP>.xcarchive
[fastlane] result: success

Validation du build

Conclure avec les livrables, les journaux et la durée

Une connexion réussie ne suffit pas à rendre un workflow réutilisable. Le premier build doit conserver la version, les commandes, l’emplacement du livrable et la durée, pour l’automatisation et le diagnostic futurs.

Récupérer le dépôt de test

Utilisez des identifiants de dépôt limités aux permissions nécessaires pour cette tâche. Notez l’identifiant du commit afin de pouvoir reproduire le même code source ultérieurement.

Entrée : identifiant du commit

Verrouiller la toolchain

Notez les versions de Xcode et du build, ainsi que les environnements Ruby et fastlane ; n’introduisez pas de mise à niveau inutile lors de la première validation.

Entrée : liste des versions

Exécuter l’archivage Release

Conservez la commande complète, le code de sortie et les journaux clés. En cas d’échec, identifiez d’abord un problème de dépendance, de configuration du projet ou d’accès, sans relancer aveuglément en boucle.

Exécution : archive

Télécharger et vérifier le livrable

Copiez l’archive vers l’emplacement convenu, vérifiez sa taille, sa structure et le résultat du téléchargement, et évitez de ne conserver qu’une copie sur le nœud.

Livrable : xcarchive

Consigner la durée de la tâche

Consignez séparément la durée de récupération des dépendances, de compilation, d’archivage et de transfert. Ces données servent à comparer les tâches futures et ne constituent pas un engagement de performance interprojets.

Sortie : détail des durées

Rassembler les éléments en cas d’échec

Ajoutez l’identifiant de commande, la région du nœud, l’heure, les étapes de reproduction, le code de sortie et des journaux anonymisés, puis suivez le parcours d’assistance correspondant au problème.

Consulter le guide de dépannage

Critères de validation finale

Un rapport reproductible et une archive téléchargeable

La vérification de l’empreinte SSH est réussie et l’architecture est arm64
Les tests d’affichage, de clavier et de reconnexion VNC sont réussis
La version Xcode et la commande de build sont consignées
Le livrable d’archive est téléchargé et soumis aux contrôles de base

Prêt ? Lancez votre première instance Debug M4 avec cette checklist

Choisissez d’abord le nœud et la durée, puis vérifiez la configuration, les options et le montant en USD. Après la livraison, effectuez la vérification de l’empreinte, la connexion à distance et le premier archivage à partir de la confirmation.

Louer maintenant Voir tous les tarifs