Choisissez d’abord la région, le modèle et la durée, puis renforcez les identifiants, vérifiez SSH, initialisez le bureau graphique et lancez votre premier build Xcode. Conservez une trace vérifiable à chaque étape.
Le choix ne dépend pas uniquement de la puce. La région, le mode d’accès, les versions de la toolchain et les responsables de l’équipe influencent directement la première heure après l’activation du nœud.
Choisissez entre Singapour, le Japon (Tokyo), la Corée du Sud (Séoul) et Hong Kong la région la mieux adaptée à vos principaux développeurs ou au chemin réseau vers vos artefacts. Tenez compte aussi des routes vers le dépôt de code et les sources de dépendances, pas seulement de votre emplacement.
SG · JP · KR · HKCommencez avec Orb M4 16 pour les builds légers ; évaluez Orb M4 24 pour les graphes de dépendances plus importants et les tâches parallèles ; choisissez Orb M4 Pro pour les builds gourmands en mémoire ou les expérimentations d’IA locales.
3 configurations au totalChoisissez le jour ou la semaine pour une validation ponctuelle, le mois ou le trimestre pour une pipeline stable. Notez d’abord la date de validation interne avant de renouveler, afin de ne pas confier une livraison à une commande temporaire sans suivi.
Jour · semaine · mois · trimestrePréparez une clé publique Ed25519 dédiée à ce nœud et vérifiez que la clé privée reste uniquement sur un appareil autorisé ou dans un système de clés contrôlé. Ne réutilisez pas une clé personnelle comme identifiant partagé par l’équipe.
Ed25519 recommandéDésignez le responsable du nœud, l’administrateur CI et le contact incident. Chaque membre utilise sa propre clé ; consignez les ajouts, modifications et révocations au lieu de couvrir toute l’équipe avec un seul identifiant.
Un identifiant par personneVerrouillez à l’avance les versions de macOS, Xcode, des outils en ligne de commande, de Ruby, Node, CocoaPods et des gestionnaires de dépendances. Inscrivez ces exigences dans le dépôt et vérifiez-les une par une lors de l’initialisation du nœud.
Versions reproductibles obligatoiresLa console affiche les régions disponibles pour chaque modèle. Les combinaisons du catalogue sont généralement commandables ; la disponibilité réelle est celle renvoyée en temps réel par la console.
Orb M4 16 : M4, 16 Go de mémoire et 256 Go de stockage ; Orb M4 24 : M4, 24 Go de mémoire et 512 Go de stockage ; Orb M4 Pro : M4 Pro, 64 Go de mémoire et 2 To de stockage.
Choisissez Singapour, le Japon (Tokyo), la Corée du Sud (Séoul) ou Hong Kong ; la durée peut être quotidienne, hebdomadaire, mensuelle ou trimestrielle. Notez le code de région et la date de renouvellement dans l’inventaire interne.
Vérifiez le modèle, la région, la durée et les options, puis passez commande. L’adresse du nœud, les informations d’accès initiales et l’état du service seront fournis dans la console ; ne les transmettez pas par un canal non autorisé.
Les informations initiales servent uniquement à établir la première connexion contrôlée. N’importez ni dépôt de production ni éléments de signature avant d’avoir vérifié les clés, ajusté les accès et consigné les informations de récupération.
Les clés des développeurs servent au diagnostic interactif ; les clés des runners ne reçoivent que les permissions nécessaires à la pipeline. Révoquez la clé d’un membre qui quitte l’équipe sans remplacer un identifiant partagé.
Avant de modifier le réseau, SSH ou la session graphique, conservez la session actuelle et vérifiez qu’un second responsable a contrôlé les informations de récupération dans la console.
Ne passez pas la vérification de l’empreinte hôte. L’adresse et le port viennent de la console ; comparez l’empreinte fiable au dossier de livraison validé par l’équipe.
# Définir les variables uniquement après avoir obtenu l’adresse dans la console
export NODE_HOST="ADRESSE_DU_NOEUD"
export NODE_PORT="22"
# Corriger les permissions de la clé privée dédiée
chmod 600 ~/.ssh/orbvps_node
# Lire et afficher l’empreinte hôte, puis la comparer au dossier de livraison
ssh-keyscan -p "$NODE_PORT" "$NODE_HOST" \
| ssh-keygen -lf -
# Établir la première connexion
ssh -p "$NODE_PORT" \
-i ~/.ssh/orbvps_node \
nodeadmin@"$NODE_HOST"
# Après la connexion, vérifier le matériel, le système et le disque
$ uname -m
arm64
$ sw_vers
$ sysctl -n machdep.cpu.brand_string
$ df -h /
$ uptimeLe bureau graphique convient à l’affichage, aux préférences système et à la première configuration interactive de Xcode. Les identifiants de connexion ne sont pas publiés ; consultez l’adresse et les informations d’accès après l’activation.
Après chaque réglage, déconnectez-vous puis reconnectez-vous pour confirmer qu’il reste effectif dans une nouvelle session.
Choisissez une résolution adaptée à votre réseau et à votre écran. Si le texte est trop petit ou l’affichage nettement lent, réduisez d’abord la résolution, puis évaluez le chemin réseau.
Harmonisez la langue système, les formats régionaux et le fuseau horaire définis par l’équipe afin de garantir la cohérence des journaux de build, des dates et des scripts automatisés.
Vérifiez que le verrouillage n’interrompt pas les tâches qui doivent rester actives, tout en limitant les accès non autorisés. Validez séparément les sessions interactives et les tâches CI.
Coupez volontairement une session graphique, reconnectez-vous, puis vérifiez que le bureau, la résolution et les processus en cours correspondent aux attentes.
Effectuez la migration en trois étapes : transférez d’abord les données vérifiables, verrouillez ensuite la toolchain, puis connectez la CI. Ne copiez pas dépôt, dépendances et configuration d’automatisation en une seule fois sans contrôle.
Ne migrez que les dépôts, fichiers de verrouillage des dépendances, scripts de build et données de test nécessaires. Excluez caches temporaires, anciens artefacts et fichiers orphelins ; vérifiez ensuite l’état du dépôt et les empreintes des fichiers clés.
Installez Xcode, les outils en ligne de commande et les gestionnaires de dépendances selon les exigences du dépôt. Enregistrez les versions réellement utilisées dans la référence ; ne remplacez pas un numéro précis par « dernière version ».
Après l’enregistrement du runner self-hosted, lancez d’abord une tâche de test contrôlée. Vérifiez les journaux d’échec, le nettoyage du cache et les étapes de récupération, puis intégrez progressivement la branche de production.
Critère de migration :Le même commit doit être compilé localement et sur le Mac dans le cloud avec la toolchain consignée, produire les mêmes résultats de test clés et pouvoir être redéployé conformément à la documentation.
Le premier build ne vise pas le temps le plus court, mais la preuve que la toolchain, les dépendances, les permissions et les chemins de sortie sont reproductibles.
Confirmez que le répertoire développeur sélectionné, la version de Xcode et le SDK disponible correspondent aux exigences du projet.
Après avoir accepté la licence Xcode, installez Ruby, Node, CocoaPods et les autres dépendances du projet en suivant strictement les fichiers de verrouillage.
Indiquez explicitement le workspace, le scheme et la configuration, puis enregistrez la sortie standard complète dans un fichier journal distinct.
Notez le commit, les versions de la toolchain, les heures de début et de fin, le code de sortie et l’emplacement des artefacts pour comparer les changements ultérieurs.
$ xcode-select -p
/Applications/Xcode.app/Contents/Developer
$ xcodebuild -version
Xcode <VERSION_DU_PROJET>
$ sudo xcodebuild -license accept
$ bundle install
$ bundle exec pod install
$ mkdir -p build-logs
$ set -o pipefail
$ xcodebuild \
-workspace App.xcworkspace \
-scheme App \
-configuration Release \
clean build \
| tee build-logs/first-success.log
** BUILD SUCCEEDED **Après l’intégration du runner self-hosted, limitez d’abord son périmètre à l’aide de labels dédiés et d’une branche de test, puis ouvrez progressivement les builds de production.
La tâche ne fait que produire l’état de l’environnement, restaurer les dépendances, exécuter les tests unitaires et lancer un build sans publication. Vérifiez le routage des labels, l’intégrité des journaux, le nettoyage du cache et l’arrêt en cas d’échec avant de connecter la branche de production.
Inscrivez les résultats ci-dessous dans le runbook de l’équipe. Le nœud peut fonctionner 365 jours par an, mais le processus de build doit toujours définir clairement les données, la supervision et les responsabilités d’intervention.
Le dépôt, la configuration de build, les informations de récupération des clés et les artefacts nécessaires disposent de copies hors du nœud, et une restauration a été vérifiée.
Récupération vérifiéeConsignez au minimum l’espace disque disponible, le code de sortie des builds, le temps d’attente des tâches et l’état en ligne du runner, avec des seuils d’alerte définis.
Un responsable est désigné pour les métriquesLe responsable principal et son remplaçant peuvent accéder aux fiches du nœud, aux journaux de build et aux tickets de la console ; le processus de relais est documenté.
Contacts principal et secondaire définisLa durée de la commande et la date de confirmation interne sont enregistrées et ne dépendent pas de la mémoire d’une seule personne. Évaluez les tâches en cours avant toute modification de configuration.
Durée enregistréeLes clés des personnes et du runner ainsi que leurs permissions sont listées et peuvent être révoquées individuellement sans affecter les autres membres.
Un enregistrement par élémentL’identifiant du nœud, l’heure de l’incident, les étapes de reproduction et les journaux désensibilisés peuvent être réunis à tout moment ; un membre autorisé peut envoyer un ticket depuis la console.
Dossier prêt à être envoyéChoisissez le modèle, la région et la durée, puis suivez ce guide après l’activation pour sécuriser l’accès, réaliser le premier build et valider la CI.