Ce guide couvre les prérequis, le choix entre deux configurations de nœuds physiques dédiés, les quatre nœuds disponibles, la première connexion SSH et la validation d’un build Xcode. Suivez les étapes dans l’ordre et terminez chacune avant de passer à la suivante.
Avant de commander, définissez les responsables de la connexion, des builds et de la gestion des accès afin de limiter les échanges après la livraison. Les cinq éléments ci-dessous doivent avoir un responsable clairement identifié.
Vérifiez que la personne qui passe la commande peut se connecter à la console et consulter les commandes, la facturation, les nœuds et l’état des équipements. Le responsable technique doit savoir qui soumet les tickets et gère les renouvellements.
Préparez une clé publique Ed25519 approuvée par l’équipe et transmettez uniquement son contenu public. Conservez la clé privée sur un appareil contrôlé ou dans un système de gestion des clés ; ne la transmettez ni par e-mail, ni par ticket, ni dans un dépôt.
Vérifiez la version cible de Xcode dans le projet, la configuration CI et les dépendances, puis notez la version minimale de macOS requise. N’indiquez pas seulement « dernière version » : conservez un numéro de version vérifiable.
Vérifiez que le nœud peut lire les dépôts requis avec une clé de déploiement limitée ou un jeton à durée courte. Définissez d’abord le périmètre minimal, puis décidez si l’écriture d’artefacts ou de statuts est nécessaire.
Pour les opérations graphiques, préparez à l’avance un client VNC ou de partage d’écran macOS. Privilégiez SSH pour l’automatisation, le diagnostic et la gestion des fichiers afin de réduire la dépendance aux sessions graphiques.
Les deux configurations utilisent des nœuds physiques Apple Silicon dédiés, et non des machines virtuelles. Singapour, Tokyo, Séoul et Hong Kong figurent au catalogue ; la disponibilité réelle est celle renvoyée en temps réel par la console lors de la commande.
M4 · 16 Go de RAM · SSD 256 Go
Idéal pour une pipeline de build iOS, la compilation macOS quotidienne, la validation des dépendances et un runner self-hosted léger fonctionnant en continu.
Critère de choix : Mesurez d’abord le pic de mémoire et le jeu de travail disque d’un build propre, puis prévoyez de l’espace pour le cache des dépendances, les journaux et les artefacts.
M4 · 24 Go de RAM · SSD 512 Go
Adapté aux espaces de travail Xcode volumineux, aux tests parallèles, aux charges conteneurisées et aux équipes qui doivent conserver davantage de caches de build et d’artefacts.
Critère de choix : Lorsque le runner compile, exécute des tests sur simulateur et traite les dépendances simultanément, surveillez en priorité le pic de mémoire et la vitesse de croissance du cache.
Choisissez un nœud proche des principaux développeurs, de la source du code ou du point d’entrée de l’orchestration. Ne comparez pas uniquement un ping ponctuel : observez aussi la stabilité pendant les heures de travail et l’expérience de bureau à distance.
La location est disponible à la journée, à la semaine, au mois ou au trimestre. Pour une validation ponctuelle, choisissez une durée correspondant au temps de test prévu ; pour une pipeline stable, tenez compte du calendrier des releases et de la responsabilité du renouvellement.
La commande détaille séparément la configuration de base, la durée, le nœud et les options. Tous les prix et règlements sont en dollars américains (USD) ; la personne qui passe la commande doit effectuer une dernière vérification avant le paiement.
Vérifiez le réseau, le montant et l’identifiant de commande selon les informations de paiement affichées dans la console. Avant le transfert, confirmez l’utilisation du réseau TRC20 et conservez la transaction pour le rapprochement.
Le paiement par carte est traité par Stripe. Après le retour de la page de paiement, vérifiez l’état de la commande et le montant facturé dans la console ; la page de retour du navigateur ne confirme pas la livraison de l’équipement.
Le nom de la configuration, la puce M4, la mémoire et le SSD de base doivent correspondre à l’offre choisie.
Confirmez la journée, la semaine, le mois ou le trimestre ; ne choisissez pas par erreur une durée longue pour une période de test.
Confirmez que Singapour, Tokyo, Séoul ou Hong Kong correspond au plan de connexion.
Confirmez l’extension SSD et le nombre de connexions en parallèle Thunderbolt 5 avant de payer.
Les moyens de paiement réellement disponibles sont ceux renvoyés par la console. Le paiement effectué ne signifie pas que l’équipement est déjà accessible : vérifiez encore l’état de la commande et les informations de livraison.
Attendez que l’équipement soit indiqué comme accessible avant de consulter l’adresse, les informations du compte et la durée de location. N’utilisez pas de conversations, anciennes captures d’écran ou informations de connexion d’une autre commande.
Tous les champs doivent provenir de la même commande. Si le nœud, l’adresse ou la durée diffère de vos attentes, interrompez la connexion et ouvrez un ticket depuis la console.
Continuez à consulter l’état de la commande dans la console. Le délai de livraison est déterminé par l’heure de confirmation affichée dans la console ; n’essayez pas à répétition une adresse qui n’a pas encore été fournie.
Dans votre ticket, indiquez l’identifiant de commande, le nœud attendu, l’état actuel de l’équipement et l’heure de constat du problème. N’ajoutez ni mot de passe, ni clé privée, ni données complètes de paiement.
Lors de la première connexion SSH, ne commencez pas par installer des dépendances : vérifiez que l’adresse cible, l’empreinte de l’hôte, l’utilisateur et les informations matérielles correspondent à la commande en cours.
$ export ZOOMMINI_HOST=assigned-host
$ ssh-keyscan -t ed25519 "$ZOOMMINI_HOST" | ssh-keygen -lf -
256 SHA256:7qV3mL9kR2nF4cX8 assigned-host (ED25519)
$ ssh build@"$ZOOMMINI_HOST"
Last login: remote session
build@zoommini-node ~ %
$ sw_vers
ProductName: macOS
ProductVersion: 15.2
BuildVersion: 24C101
$ system_profiler SPHardwareDataType
Hardware:
Model Name: Mac mini
Chip: Apple M4
Memory: 16 GB
$ uname -m
arm64Enregistrez l’adresse attribuée dans une variable d’environnement temporaire ou dans la configuration SSH afin d’éviter une adresse incorrecte dans l’historique des commandes. Si le port n’est pas celui par défaut, notez également le paramètre de port.
Comparez caractère par caractère l’empreinte Ed25519 relevée localement avec celle de la fiche de livraison. En cas de divergence, interrompez la connexion et n’acceptez pas directement la nouvelle valeur.
sw_vers pour vérifier la version de macOS,system_profiler pour vérifier la puce et la mémoire,uname -m doit renvoyer arm64.
Vérifiez d’abord la sélection de Xcode, lancez ensuite le build du projet, puis exécutez les tests automatisés. Conservez le code de sortie et les journaux clés à chaque étape ; ne vous fiez pas uniquement à l’interface.
$ xcodebuild -version
Xcode 16.2
Build version 16C5032aLa version de Xcode et la version de build correspondent à la matrice du projet et la commande se termine avec le code 0.
$ xcodebuild -scheme App build
Prepare packages
CompileSwiftSources normal arm64
Ld App normal arm64
** BUILD SUCCEEDED **La sortie se termine par BUILD SUCCEEDEDet ne contient aucune erreur de signature, de dépendance ou d’espace disque.
$ fastlane ios test
Resolving Swift Package Manager dependencies
Test Suite 'All tests' passed
Executed 48 tests, with 0 failures
fastlane.tools finished successfullyLe nombre de tests correspond aux attentes, le nombre d’échecs est de 0, fastlane se termine normalement et le processus renvoie le code 0.
Commencez par exécuter xcode-select -p pour consulter le répertoire développeur actuel, puis basculez selon la matrice des versions de l’équipe. Ne modifiez pas directement les fichiers du projet pour contourner un problème de version.
Vérifiez les autorisations du dépôt, le chemin du gestionnaire de paquets et le périmètre d’accès réseau. Avant de vider le cache, sauvegardez les journaux d’erreur afin de conserver les premières traces de l’échec.
Vérifiez le chargement des certificats, des profils de provisioning et des autorisations du runner. Les secrets doivent être injectés par un système de gestion contrôlé, jamais écrits dans les scripts ou les journaux de build.
La validation confirme uniquement que la chaîne d’outils fonctionne. Avant l’intégration officielle à la CI/CD, mettez à jour les identifiants, gérez les clés publiques, révoquez les accès inutiles et appliquez les privilèges minimaux au runner.
Selon les instructions de livraison, remplacez les identifiants initiaux concernés. Utilisez un mot de passe unique et contrôlé, sans le réutiliser sur votre poste local, dans un dépôt ou sur un autre nœud.
Configurez séparément les clés publiques des utilisateurs et des identités automatisées autorisés. Ne partagez pas une même clé privée entre plusieurs personnes ; le commentaire de la clé publique doit permettre d’en retracer l’usage.
Supprimez les clés publiques, jetons de dépôt, privilèges administrateur et autorisations de bureau à distance ajoutés temporairement pendant les tests. Révoquez immédiatement les accès des personnes ayant quitté l’équipe et des runners désactivés.
Le runner doit uniquement lire les dépôts nécessaires, exécuter les scripts prévus et écrire dans les emplacements d’artefacts autorisés. N’accordez pas par défaut de privilèges d’administration système ni de jetons interprojets.
N’intégrez le nœud à l’orchestration de production que lorsque les cinq conditions sont réunies : champs de commande cohérents, empreinte SSH identique, spécifications système conformes, codes de sortie du build et des tests égaux à 0, et accès temporaires révoqués.
Commencez par choisir la configuration, le nœud et la durée. Dès que l’équipement est accessible, suivez l’ordre de cette page pour vérifier l’empreinte, le système, le build et les accès.