De la validation à un fonctionnement stable

Intégrez votre Mac dans le cloud à votre flux de build

Après réception des informations de l’appareil, vérifiez la commande et le nœud, puis configurez la connexion, reproduisez la chaîne d’outils et enregistrez l’exécuteur CI. Chaque étape indique les commandes de contrôle, les critères de réussite et les éléments à conserver en cas d’erreur.

Louer un Mac dans le cloud Voir les configurations et les tarifs

Nœuds disponibles: 5nœuds physiques
Configurations disponibles: 2Macs physiques dédiés
Parcours opératoire: 9étapes de contrôle

Tableau de passation initiale Valider dans l’ordre

Vérifier le dossier de livraison

Le nœud, la configuration, la version du système, la durée de location et les identifiants d’accès doivent correspondre à la confirmation de commande.

Validation

Établir la première session

Commencez par vérifier la connexion en ligne de commande, puis établissez une session graphique et testez la reprise après déconnexion selon vos besoins.

Connexion

Reproduire l’environnement de développement

Verrouillez Xcode, les outils requis et le répertoire de travail au lieu de copier intégralement les fichiers de l’ancienne machine.

Configuration

Lancer un build réel

Exécutez une archive ou un test sur le dépôt réel, puis consignez la durée, les journaux et la vérification des artefacts.

Vérification

Préparation

Identifiez d’abord l’appareil, le nœud et la durée de location

Ne commencez pas la migration avant d’avoir vérifié les informations. Connectez-vous à la console et comparez chaque champ avec les détails de l’appareil. En cas d’écart, conservez les informations affichées et ouvrez un ticket.

Nœud et chemin réseau

Vérifiez que le nœud se trouve à Singapour, Tokyo au Japon, Séoul en Corée du Sud, Hong Kong ou dans l’est des États-Unis. Notez son code et testez le chemin depuis votre réseau professionnel principal.

Confirmer le lieu d’accès principal de l’équipe et le fuseau horaire du nœud
Tester séparément le réseau professionnel et le réseau de secours
Consigner la latence, la gigue et les pertes de paquets, plutôt que de regarder un seul ping

Configuration de l’appareil

Le catalogue comprend deux niveaux. À réception des informations, vérifiez séparément la puce, la mémoire et le stockage.

Configuration de base : M4, 16 Go, 256 Go
Configuration haute performance : M4 Pro, 64 Go, 2 To
Le stockage supplémentaire est défini par la confirmation de commande

Système et informations d’accès

Vérifiez la version du système, le nom d’hôte, l’adresse de connexion, le port et les identifiants temporaires. Après la première connexion, faites-les immédiatement tourner selon les règles de l’équipe.

Ne collez pas de mots de passe ni de clés privées dans des journaux publics
Conservez les identifiants dans un outil de gestion des secrets contrôlé
Confirmez les informations nécessaires séparément pour la connexion en ligne de commande et la connexion graphique

Durée de location et date de sortie

Pour une location à la journée, à la semaine, au mois ou au trimestre, définissez avant de commencer le moment d’exportation des données et l’arrêt des tâches afin de ne pas repousser le nettoyage à la dernière minute.

Consigner les dates de début et de fin de location
Prévoir du temps pour exporter les artefacts et nettoyer les caches
Désigner le responsable interne des renouvellements ou ajustements

Guide de première connexion

Vérifiez d’abord l’accessibilité en ligne de commande, puis établissez une session graphique

La ligne de commande convient à la validation de base et à l’automatisation ; la session graphique convient à Xcode, aux simulateurs et aux opérations nécessitant une interface visuelle. Validez séparément les deux méthodes : la réussite de l’une ne garantit pas le bon fonctionnement de l’autre.

Connexion en ligne de commande

Établir une session minimale vérifiable

1
Vérifier les informations cibles
Copiez l’adresse de l’hôte, le port et le nom d’utilisateur depuis la console. Vérifiez les caractères et la casse ; ne réutilisez pas d’informations périmées d’un ancien ticket.
2
Vérifier l’empreinte de l’hôte
Comparez-la aux informations de livraison lors de la première connexion. Si elle change, interrompez la connexion et vérifiez la cause ; ne supprimez pas simplement l’enregistrement local pour réessayer.
3
Effectuer les contrôles en lecture seule
Confirmez l’utilisateur actuel, le nom d’hôte, la version du système, les disques et le chemin Xcode ; n’installez ni ne supprimez immédiatement de logiciel.
4
Vérifier la reprise après déconnexion
Déconnectez-vous volontairement puis reconnectez-vous pour confirmer le mécanisme de reprise de session, la gestion des tâches longues et le répertoire de sauvegarde des journaux.

Accès graphique distant

Valider séparément la qualité d’affichage et la stabilité des tâches

1
Commencer avec une qualité d’affichage prudente
Commencez avec une résolution et une qualité colorimétrique réduites pour vérifier la stabilité de la session, puis augmentez progressivement les réglages afin de ne pas confondre saccades d’affichage et problème de performances.
2
Protéger les identifiants et le presse-papiers
N’exposez pas de mots de passe, clés privées ou mots de passe de certificats lors du partage d’écran, d’un enregistrement ou dans un presse-papiers non contrôlé.
3
Verrouiller les sessions sans surveillance
Verrouillez la session graphique avant de quitter l’appareil. En cas de collaboration, désignez clairement la personne qui agit à chaque instant pour éviter les modifications concurrentes.
4
Vérifier l’état après reconnexion
Après une reconnexion, vérifiez que les applications au premier plan, les processus de build et les écritures sur disque sont toujours actifs ; ne concluez pas à l’échec d’une tâche sur la seule base d’un affichage figé.

Contrôle rapide dans le terminal

Établir une base de référence avec des commandes en lecture seule

Les commandes ci-dessous couvrent la puce, la mémoire, le disque, la version du système, le réseau et les chemins des outils de développement. Enregistrez la sortie, mais supprimez les noms d’utilisateur, adresses de dépôts internes et autres champs sensibles avant d’ouvrir un ticket.

DPLYMAC / FIRST-RUN CHECK

printf '\n== CHIP ==\n'
system_profiler SPHardwareDataType | grep -E "Chip|Memory"

printf '\n== DISK ==\n'
diskutil info / | grep -E "Device Node|File System|Disk Size|Free Space"

printf '\n== SYSTEM ==\n'
sw_vers
uname -m

printf '\n== NETWORK ==\n'
route -n get default | grep interface
ping -c 5 1.1.1.1

printf '\n== XCODE ==\n'
xcodebuild -version
xcode-select -p
swift --version

printf '\n== TOOL PATHS ==\n'
command -v git
command -v ruby
command -v fastlane

Comment savoir si le contrôle est réussi

La puce et la mémoire correspondent à la configuration commandée
Le volume racine est accessible en lecture-écriture et l’espace libre suffit aux tâches
L’architecture système renvoie arm64
L’interface réseau par défaut existe et les tests consécutifs ne montrent pas de perte importante
Xcode et les outils en ligne de commande pointent vers les versions attendues

Éléments à conserver

Heure d’exécution de la commande et nœud
La commande complète, pas seulement la dernière ligne
La sortie originale et la version anonymisée destinée au ticket
Résultat attendu, résultat réel et nombre de reproductions

Xcode et environnement de signature

Verrouillez d’abord la chaîne d’outils, puis importez les éléments nécessaires au build

La cohérence de l’environnement repose sur des versions explicites et des étapes reproductibles, non sur la copie du répertoire utilisateur complet d’une ancienne machine. Importez uniquement le matériel de signature nécessaire et nettoyez-le avant la fin de la location.

Élément à contrôler Opération Critère de réussite

Version de Xcode

Exécutez xcodebuild -version, consignez la version majeure et le numéro de build ; si le projet impose une version, inscrivez l’exigence dans la documentation du dépôt.

La version correspond aux exigences du projet

Outils en ligne de commande

Exécutez xcode-select -p, basculez si nécessaire vers un chemin approuvé par l’équipe ; n’effectuez pas de mise à niveau improvisée en cours de tâche.

Le chemin pointe vers le Xcode cible

Importation des certificats

Importez uniquement les certificats nécessaires au projet actuel, utilisez un transfert contrôlé et limitez l’accès au trousseau.

L’identité de signature cible est identifiable

Profil de provisioning

Vérifiez l’identifiant de l’app, l’équipe, les capacités et l’état de validité ; évitez les fichiers hérités d’autres projets.

La cible d’archive correspond à la configuration du projet

Déverrouillage du trousseau

Déverrouillez-le dans le script de build pendant la durée minimale, puis reverrouillez-le à la fin. N’écrivez pas le mot de passe dans le dépôt ou les journaux ordinaires.

Le build non interactif peut lire les éléments nécessaires

Vérification avant build

Effectuez d’abord la résolution des dépendances, l’inventaire du projet et le contrôle de la signature, puis lancez l’archive complète.

L’échec survient avant le build officiel

Parcours de migration

Divisez la migration en trois passations : données, chaîne d’outils et exécuteur

Ne modifiez qu’une variable à la fois et conservez un point de retour. En cas d’écart de build, vous pourrez déterminer s’il vient des données, des dépendances ou de l’enregistrement CI.

Passation 01

Synchronisation des données

Entrées: Code source, ressources nécessaires, fichiers de verrouillage des dépendances et scripts de build
Opération: Récupérez en priorité depuis le dépôt ; vérifiez séparément les gros fichiers et ne copiez ni caches inutiles ni anciens artefacts
Vérification: La version, le nombre de fichiers et les sommes de contrôle correspondent aux attentes ; aucun fichier sensible n’est entré dans le dépôt
Échecs courants: Fichiers oubliés par les règles d’exclusion, différences de casse dans les chemins, changements de sauts de ligne, perte des bits de permission
Point de retour: Conservez un répertoire de travail propre afin de pouvoir supprimer la synchronisation et la récupérer à nouveau

Passation 02

Reproduction de la chaîne d’outils

Entrées: Exigences Xcode, liste des dépendances, fichiers de verrouillage des gestionnaires de paquets et versions des environnements d’exécution des scripts
Opération: Installez l’ensemble minimal d’outils selon la documentation, verrouillez les versions et inscrivez explicitement les chemins et variables d’environnement dans la configuration de tâche
Vérification: La résolution des dépendances réussit et le même commit produit le même résultat en commande locale et dans le script automatisé
Échecs courants: Dépendances globales implicites, différence de Ruby par défaut, mauvais chemin Xcode, cache pollué
Point de retour: Conservez la liste des versions et les journaux d’installation ; vous pourrez vider le cache des outils et recommencer

Passation 03

Intégration CI

Entrées: Informations d’enregistrement de l’exécuteur, étiquettes de file, répertoire de travail, règles de cache et limite de concurrence
Opération: Enregistrez un seul exécuteur, lancez d’abord une tâche de contrôle en lecture seule, puis un pipeline complet sur un dépôt réel
Vérification: La tâche est correctement planifiée et le code de sortie, les journaux, les résultats de test et les artefacts sont traçables
Échecs courants: Étiquettes incompatibles, réutilisation du répertoire de travail, clé de cache trop large, plusieurs tâches utilisant la même ressource
Point de retour: Désenregistrez l’exécuteur et revenez au build manuel sans affecter les données ni la chaîne d’outils déjà vérifiées

Intégration CI/CD

Un exécuteur enregistré ne signifie pas que le pipeline est fiable

Après l’enregistrement, validez au moins une tâche avec cache froid, une avec cache chaud et une nouvelle tentative après échec. Le répertoire de travail, le cache et la concurrence doivent être gérés explicitement par le pipeline.

Contrôles d’intégration des exécuteurs CI courants
Plateforme	Contrôle de l’enregistrement	Répertoire de travail	Stratégie de cache	Recommandation de concurrence
GitHub Actions	Vérifiez les étiquettes du Runner auto-hébergé et la portée du dépôt ou de l’organisation cible	Utilisez un espace de travail distinct par tâche et nettoyez les fichiers temporaires à la fin	La clé de cache inclut le résumé du fichier de verrouillage, Xcode et l’architecture	Validez d’abord une seule tâche, puis augmentez la concurrence selon la pression mémoire et disque
GitLab CI	Vérifiez les étiquettes du Runner, les droits des branches protégées et l’état de l’exécuteur	Évitez de partager des répertoires inscriptibles et des chemins d’artefacts portant le même nom entre projets	Délimitez le cache par projet, branche et résumé des dépendances	Utilisez des files distinctes pour les archives, les tests et les contrôles légers
Jenkins	Vérifiez les étiquettes du nœud, le répertoire racine distant et la portée des identifiants	Nettoyez le workspace à la fin du pipeline tout en conservant les journaux nécessaires	Gérez séparément le cache des dépendances et les artefacts de build	Limitez le nombre de tâches d’archivage lourdes utilisant simultanément le même appareil
Runner autogéré	Consignez le mode de démarrage du service, l’utilisateur d’exécution et les conditions de prise en charge des tâches	Créez un répertoire par identifiant de tâche et effectuez un nettoyage déterministe à la sortie	Définissez le propriétaire du cache, sa capacité maximale et ses conditions d’expiration	Contrôlez les ressources avec une file au lieu de compter sur une course aux verrous entre scripts

Enregistrement terminé

L’exécuteur est en ligne, les étiquettes correspondent, l’utilisateur d’exécution est correct et seuls les dépôts et identifiants autorisés sont accessibles.

Tâche reproductible

Le même commit produit des artefacts cohérents avec cache froid comme chaud, et les échecs conservent un code de sortie explicite.

Répertoire récupérable

Les fichiers temporaires de signature, données dérivées et intermédiaires de build suivent des règles de nettoyage déterministes, sans suppression manuelle élément par élément.

Concurrence plafonnée

Définissez la file selon la charge CPU, mémoire et SSD afin que plusieurs archives ne se disputent pas les ressources.

Diagnostic des performances

Identifiez d’abord la couche qui constitue le goulot d’étranglement, puis ajustez les paramètres

Consignez au minimum l’heure, le nœud, la version soumise, les étapes de reproduction et le résultat comparatif. Dire seulement « c’est lent » ne permet pas de distinguer la pression sur les ressources, le chemin réseau et la session graphique.

CPU

Déterminez s’il s’agit d’un calcul continu ou d’un pic bref

Consignez les processus fortement sollicités, le nombre de threads et l’étape de la tâche. Comparez une tâche seule et des tâches concurrentes, puis recherchez les builds répétés, tests incontrôlés ou indexations en arrière-plan.

Échantillonnage des processus

Mémoire

Examinez la pression mémoire et l’activité de swap

Consignez la mémoire maximale, la mémoire compressée et l’évolution du swap. Si l’échec survient uniquement en concurrence, réduisez d’abord la concurrence avant de comparer ; ne l’attribuez pas immédiatement au réseau.

Comparaison de charge

SSD

Distinguez le manque de capacité de la saturation des lectures-écritures aléatoires

Vérifiez l’espace libre, les données dérivées, le cache des dépendances et les anciens artefacts. Avant tout nettoyage, consignez la taille des répertoires afin de préserver les éléments utiles au diagnostic.

Capacité et E/S

Réseau

Comparez latence, gigue, pertes de paquets et débit

Effectuez des tests consécutifs depuis un réseau local fixe et comparez-les à un réseau de secours. Si la récupération du dépôt est lente, distinguez également le chemin vers le nœud de la réponse du service de dépendances.

Échantillonnage continu

Session graphique

Un affichage saccadé ne signifie pas que le processus de build est plus lent

Refaites le test après avoir réduit la résolution et la qualité colorimétrique, tout en observant l’exécution de la tâche en ligne de commande. Consignez l’état de premier plan et d’arrière-plan après reconnexion.

Séparation de session

Sécurité et sortie

Préparez la passation finale dès la première connexion

Les identifiants, éléments de signature, artefacts de build et caches ont chacun un propriétaire défini. Avant la fin de la location, exportez, vérifiez, supprimez et contrôlez à nouveau dans cet ordre, sans compter sur votre mémoire pour le nettoyage.

Exécution continue

Identifiants et autorisations

Faites tourner les identifiants temporaires après la première connexion
Appliquez le principe du moindre privilège par dépôt et par tâche
Vérifiez régulièrement la portée des exécuteurs et des clés d’automatisation
N’écrivez pas de mots de passe dans les scripts, dépôts ou journaux ordinaires

Avant l’exportation

Artefacts et données

Exportez les archives, rapports de test et journaux nécessaires
Vérifiez le nombre de fichiers et les sommes de contrôle à l’emplacement cible
Confirmez la synchronisation des commits et des branches distantes du dépôt
Consignez les bases de build qui doivent être conservées

Avant la fin de la location

Nettoyage de l’environnement

Désenregistrez l’exécuteur CI et révoquez les identifiants associés
Supprimez les certificats, profils de provisioning, clés privées et codes de récupération
Supprimez les répertoires de travail, fichiers temporaires et caches sensibles
Vérifiez à nouveau le dossier de téléchargement, le bureau et l’historique des commandes

Assistance et escalade

Donnez au ticket les conditions nécessaires à la reproduction dès le premier échange

Pour un problème concernant une commande existante, connectez-vous à la console et ouvrez un ticket. Si vous ne pouvez pas vous connecter, envoyez un e-mail à support@deploymac.com. Avant l’envoi, supprimez les mots de passe, clés privées, mots de passe de certificats et autres identifiants sensibles.

Modèle de rapport d’incident Copiez les champs, pas les informations sensibles

Identifiant de commande

Indiquez l’identifiant affiché dans la console permettant de retrouver la commande

Nœud

Singapour, Tokyo au Japon, Séoul en Corée du Sud, Hong Kong ou est des États-Unis

Heure de l’incident

Indiquez le fuseau horaire ainsi que la première occurrence et la dernière reproduction

Configuration de l’appareil

Configuration de base ou haute performance, avec les informations de stockage supplémentaire

Étapes de reproduction

Partez d’un état propre et énumérez chaque étape dans l’ordre réellement exécuté

Sortie des commandes

Joignez les commandes complètes, les codes de sortie et la sortie anonymisée, pas seulement une capture d’écran

Résultat attendu

Décrivez l’état, le fichier ou la valeur de retour normalement attendus

Résultat réel

Décrivez l’écart, le nombre de reproductions et l’impact éventuel sur toutes les tâches

Actions déjà tentées

Énumérez les actions effectuées, comme les nouvelles tentatives, reconnexions, réductions de concurrence ou purges de cache, avec leurs résultats

Commandes existantes et problèmes de connexion

Le ticket ouvert depuis la console peut être associé à la commande, au nœud et à l’appareil. Il convient aux vérifications de livraison, anomalies de connexion et problèmes d’exécution.

Ouvrir un ticket dans la console

Pas encore de commande ou connexion impossible

Précisez dans l’e-mail l’usage prévu, le nœud cible, la durée de location estimée et l’impact du problème. N’envoyez aucun mot de passe, clé privée ou mot de passe de certificat.

Envoyer un e-mail à l’assistance

Étape suivante

Choisissez la configuration selon la charge, puis commencez la première connexion

La configuration de base convient aux builds légers et au développement quotidien ; la configuration haute performance convient aux expériences gourmandes en mémoire, à la concurrence entre projets et aux builds plus lourds. Les deux sont des Macs physiques dédiés, et non des machines virtuelles.

Louer un Mac dans le cloud Comparer les deux configurations