Ce guide de prise en main transforme la commande, la connexion, la migration et la validation en actions vérifiables. Vérifiez d’abord la configuration et les limites d’accès, puis déployez le code et les outils de build afin d’éviter d’écrire des données sensibles avant d’avoir contrôlé l’environnement.
La région, la mémoire et la durée de location influencent directement la méthode de migration. Préparez d’abord une fiche d’exécution concise : c’est plus fiable que de compléter les prérequis dans l’urgence après la commande.
Précisez si la tâche principale concerne un build Xcode, un runner self-hosted, l’inférence d’un modèle local ou le traitement multimédia. Choisissez ensuite parmi les nœuds de Singapour, Tokyo (Japon), Séoul (Corée du Sud) et Hong Kong celui qui est le plus proche de votre équipe ou de vos services dépendants.
Pour une adaptation courte ou des builds légers, évaluez d’abord le BookaMac M4 ; pour la concurrence avec beaucoup de mémoire, l’inférence de modèles et les tâches multimédias lourdes, évaluez le BookaMac M4 Pro. Choisissez une durée à la journée, à la semaine, au mois ou au trimestre.
Préparez un client SSH et un client VNC fonctionnels. Générez localement une paire de clés SSH dédiée et ne transmettez que la clé publique. Conservez la clé privée sur un appareil contrôlé ; ne l’envoyez ni par e-mail ni via un ticket.
Les deux offres sont des Mac mini physiques dédiés, et non des machines virtuelles. Avant de créer la commande, vérifiez le modèle, le nœud, la durée et le stockage supplémentaire ; la console renvoie en temps réel la disponibilité et les informations finales de la commande.
La livraison terminée ne signifie pas que vous pouvez immédiatement écrire des données. Vérifiez d’abord la configuration et les limites de connexion, puis récupérez les dépôts privés ou importez les éléments de signature.
Vérifiez que la région sélectionnée dans la commande correspond à celle affichée sur la page de livraison. Ne déduisez pas l’emplacement du nœud uniquement de la vitesse de connexion.
Vérifiez la puce, la mémoire et la capacité du disque dans les informations système, puis comparez chaque élément avec la page de confirmation de la commande.
Vérifiez la source de l’adresse SSH, du port, du nom d’utilisateur et de l’empreinte de l’hôte, puis enregistrez le résultat lors de la première connexion.
Confirmez la portée d’utilisation des identifiants temporaires, la procédure de remplacement et le point d’accès. Ne transférez pas les identifiants complets dans un canal partagé.
Définissez pour chaque étape les entrées, les actions et le résultat de la vérification. Si l’étape précédente n’est pas validée, évitez de transférer davantage de dépôts, d’identifiants ou de tâches vers le nœud.
Commencez par récupérer un dépôt qui peut être compilé de manière autonome, puis vérifiez la branche, le hash du commit, les sous-modules et les ressources volumineuses. Reconstruisez les caches de dépendances à la demande ; ne copiez pas directement un cache système dont l’origine est inconnue.
Vérifiez le répertoire développeur actuel, installez les outils en ligne de commande explicitement requis par le projet et restaurez les dépendances à l’aide du fichier de verrouillage. Ne commencez pas par mettre à niveau tous les outils globalement pour tenter ensuite d’expliquer les écarts de build.
Attribuez des libellés explicites au nœud, isolez le répertoire de travail, limitez la concurrence et lancez d’abord un pipeline de validation sans étape de publication. Les journaux ne doivent afficher ni clés, ni jetons, ni éléments de signature complets.
La colonne de droite contient les adresses utilisées dans les exemples de documentation. En pratique, utilisez l’adresse de connexion, le nom d’utilisateur, l’espace de travail du projet et la cible de build indiqués sur la page de livraison.
$ ssh build@203.0.113.24
The authenticity of host is confirmed.
Connected to dedicated Mac node
$ xcode-select -p
/Applications/Xcode.app/Contents/Developer
$ xcodebuild \
-workspace Sample.xcworkspace \
-scheme Sample \
-configuration Debug \
build
** BUILD SUCCEEDED **
$ bundle exec fastlane env
System Locale: zh_CN
Xcode Path: /Applications/Xcode.app
Environment check completedPrivilégiez SSH pour l’automatisation quotidienne. Utilisez un client VNC uniquement pour consulter l’interface de Xcode, un simulateur ou des outils graphiques.
Utilisez un client VNC de confiance et renseignez l’adresse, le port et les identifiants fournis sur la page de livraison. N’exportez pas la configuration de connexion vers un répertoire synchronisé publiquement et ne laissez pas le client enregistrer définitivement des identifiants partagés.
Lors de la première connexion, commencez avec une résolution et une qualité de couleur modérées. Si la latence est importante, réduisez d’abord la qualité d’image et vérifiez votre réseau local ; ne confondez pas la durée du build avec la latence d’affichage.
La synchronisation du presse-papiers convient aux commandes courtes et au texte courant, mais ne doit pas servir à transmettre une clé privée, un jeton d’accès complet ou des identifiants non masqués. Pour les configurations sensibles, utilisez un processus de fichiers contrôlé et vérifiez les permissions.
Après les opérations graphiques, quittez les outils concernés, verrouillez l’interface graphique macOS et déconnectez la session VNC. Les tâches longues doivent être gérées par un script ou un runner, sans dépendre d’une fenêtre de bureau laissée ouverte.
Pouvoir se connecter ne prouve que l’accès fonctionne. Une véritable validation doit couvrir le code, les dépendances, le build, les journaux et le réseau, tout en conservant une référence réutilisable.
Si un élément échoue, notez d’abord la commande, le code de sortie, l’heure et les journaux associés, puis réduisez les variables. Ne changez pas simultanément Xcode, les versions des dépendances et la configuration réseau : la cause réelle deviendrait difficile à isoler.
La branche cible et le hash du commit sont corrects ; les sous-modules et les ressources volumineuses sont complets.
Le fichier de verrouillage est appliqué, la commande d’installation est reproductible et aucune dépendance importante n’a été mise à niveau par inadvertance.
La cible indiquée est compilée avec succès ; l’emplacement, la taille et le mode de génération des artefacts sont traçables.
Le journal complet est archivé, les champs sensibles sont masqués et le code de sortie ainsi que l’identifiant de tâche sont clairement indiqués.
Les dépôts et points de terminaison nécessaires au projet sont accessibles, sans ouverture d’accès sans rapport avec la tâche.
Effectuez les réglages de sécurité immédiatement après la première validation, puis revérifiez-les lors du transfert à l’équipe, de la modification du runner et avant la fin de la location.
Après la première vérification, remplacez le mot de passe ou les identifiants temporaires et confirmez que les anciens ne sont plus utilisables.
Utilisez une clé publique SSH dédiée, vérifiez authorized_keys et restreignez les permissions du fichier de clé privée local.
Attribuez à chaque membre un mode d’accès traçable et évitez qu’un même compte administrateur soit partagé durablement.
Supprimez les archives de test, téléchargements temporaires, caches obsolètes et copies d’identifiants inutilisées, puis vérifiez l’espace restant.
Consignez les changements de version de Xcode, les mises à niveau de dépendances, les libellés du runner et les ajustements réseau afin de faciliter les prochains diagnostics.
Définissez où exporter les artefacts de build, les modifications du dépôt et les journaux nécessaires ; ne repoussez pas le nettoyage des données après la fin de la location.
Les commandes, renouvellements et paramètres de l’hôte sont gérés depuis la console. Les seuls moyens de paiement pris en charge sont USDT-TRC20 et Visa / Mastercard / Amex (via Stripe), avec une facturation en dollars américains (USD). Les moyens réellement disponibles sont ceux renvoyés par le système de paiement.