Migration CircleCI Machine Runner 3 : validation macOS 2026

Le scénario le plus dangereux n’est pas nécessairement un service qui refuse de démarrer. C’est un ancien nœud qui cesse d’accepter les tâches alors que le nouveau service n’est pas opérationnel, ou qui apparaît disponible dans CircleCI sans pouvoir exécuter correctement une compilation, accéder aux dépendances privées ou restituer les artefacts.

La compatibilité annoncée d’un fichier de configuration ne prouve pas que le comportement d’exécution sera identique. Le répertoire de travail, l’utilisateur effectif, les permissions, les variables d’environnement, le cache du task-agent et le mode de démarrage peuvent modifier le résultat d’une même tâche. Une migration CircleCI Machine Runner 3 sur macOS doit donc être traitée comme une validation de production, et non comme une simple installation de paquet.

Avant toute intervention, le responsable de la migration doit établir une fiche minimale pour chaque nœud :

Cette cartographie évite une erreur fréquente : déclarer le pilote « prêt » parce que le service est visible, alors que le projet de publication n’est pas autorisé à l’utiliser ou que le nœud n’a plus accès à la chaîne de signature.

La migration de CircleCI launch agent vers Machine Runner 3 doit commencer par la suppression contrôlée des restes de l’ancien mécanisme. Le guide officiel décrit la procédure macOS à suivre ; il ne faut pas improviser une seconde méthode de lancement dans le même hôte en suivant les étapes officielles de migration.

La vérification doit couvrir le fichier du launch agent, son répertoire d’installation et le processus encore actif. Un ancien service laissé en place peut provoquer une concurrence invisible : deux processus lisent des paramètres différents, l’un récupère une tâche pendant que l’autre est considéré comme disponible, ou le retour arrière réactive une configuration incomplète.

Le contrôle opérationnel peut être mené ainsi :

• arrêter l’ancien launch agent selon la procédure CircleCI ;
• confirmer que le processus ne reste pas actif ;
• relever le chemin de l’ancien binaire et les fichiers de configuration associés ;
• archiver les journaux utiles à l’audit, sans conserver de jeton en clair ;
• vérifier qu’un seul mécanisme de démarrage sera activé pour le pilote ;
• installer Machine Runner 3 uniquement depuis la méthode décrite par CircleCI ;
• conserver la version, la source du paquet, le journal d’installation et l’identité du compte qui a réalisé l’opération.

Le guide d’installation macOS doit rester la référence pour le paquet, le service et la vérification de l’état ; les versions, les conditions de prise en charge et les changements ultérieurs doivent être contrôlés dans le changelog CircleCI, plutôt que déduits d’une ancienne procédure.

Attention : un retour arrière ne signifie pas seulement « réinstaller l’ancien agent ». Il faut définir à l’avance si le pilote revient à l’ancien service ou si les tâches sont dirigées vers un nœud de secours. Réactiver deux modes de démarrage sur le même Mac pendant une panne rend le diagnostic beaucoup plus incertain.

Le contrôle de provenance du paquet est également pertinent dans un environnement d’entreprise. L’équipe doit relever la signature et l’état de notarisation du produit installé, puis conserver ces éléments avec l’inventaire. En cas de doute, l’installation est bloquée jusqu’à confirmation dans la documentation et les artefacts officiels, au lieu d’utiliser une copie conservée sur un poste de travail.

Le fichier config.yaml peut constituer un point de départ, mais il ne doit pas être considéré comme une preuve de compatibilité comportementale. La référence de configuration Machine Runner 3 doit être relue champ par champ, notamment pour le répertoire de travail, le nettoyage, le mode du runner, le préfixe de commande, la durée maximale d’une tâche et le comportement du cache du task-agent.

La validation se déroule sur une tâche de référence qui ne contient aucun secret de production. Elle doit représenter les opérations réellement sensibles sans pouvoir publier :

• récupération d’un dépôt de test ;
• installation ou restauration des dépendances autorisées ;
• compilation d’un projet représentatif ;
• production de journaux lisibles ;
• vérification du code de sortie ;
• téléversement d’un artefact sans valeur sensible.

Les points suivants méritent une comparaison explicite entre l’ancien nœud et le pilote :

Le point important n’est pas de reproduire chaque particularité historique. Si l’ancien nœud dépend d’un chemin local, d’une variable définie par le profil interactif ou d’une permission accordée manuellement, la migration doit rendre cette dépendance visible et décider si elle est encore légitime.

Cette étape répond aussi à la question de la réutilisation de l’ancien config.yaml : il peut être comparé et adapté, mais il ne doit pas être copié puis déclaré valide sans exécuter la tâche de référence. Toute différence de chemin, d’utilisateur ou de nettoyage doit être inscrite comme écart accepté ou corrigée avant le passage suivant.

Un self-hosted runner CircleCI ne doit pas être sélectionné uniquement parce qu’il est en ligne. Le namespace, la classe de ressource, le jeton d’authentification et la configuration du projet doivent tous pointer vers le nœud attendu. Une erreur de routage peut envoyer un projet non approuvé vers un Mac qui conserve une identité de signature ou un accès au réseau interne.

La campagne d’essai doit comprendre au minimum deux catégories de projet : un flux de confiance destiné à la publication et un projet de test qui ne doit pas accéder à cette ressource. Pour chaque catégorie, l’équipe conserve la preuve de l’autorisation ou du refus. Les politiques de configuration CircleCI pour les runners auto-hébergés servent à formaliser cette séparation au niveau de l’organisation.

La liste de contrôle de routage doit confirmer les points suivants :

• la classe de ressource du pilote est explicitement identifiée ;
• seuls les projets autorisés peuvent la demander ;
• un projet de test non autorisé reçoit un refus vérifiable ;
• le jeton n’est présent ni dans le dépôt, ni dans un script partagé, ni dans les journaux ;
• la personne chargée de sa rotation est nommée ;
• la configuration du projet ne repose pas sur une valeur héritée de l’ancien service ;
• les journaux ne révèlent pas le chemin d’un trousseau, d’une clé privée ou d’un profil de provisioning.

La séparation doit être plus stricte lorsque le Mac porte la signature de production. Un compte d’exécution dédié et une classe de ressource dédiée réduisent la portée d’un projet compromis. Les tâches de test général ne doivent pas entrer dans le même domaine de confiance simplement parce qu’elles nécessitent elles aussi macOS.

Le nettoyage du répertoire de travail est une condition de sécurité, pas une amélioration facultative. Une tâche suivante ne doit pas pouvoir lire le dépôt précédent, ses variables, ses archives, son trousseau temporaire, son profil de provisioning ou ses artefacts intermédiaires.

Pour le vérifier, deux projets de test isolés peuvent être utilisés. Le premier crée des marqueurs non sensibles dans le répertoire de travail, les variables d’environnement et les emplacements temporaires prévus par la chaîne. Après sa fin, le second recherche ces marqueurs et doit obtenir un résultat négatif. Cette méthode ne prouve pas à elle seule l’absence de toute persistance, mais elle révèle rapidement un nettoyage inactif ou un mauvais chemin de travail.

La preuve doit inclure :

• l’état du répertoire avant et après la tâche ;
• les fichiers de cache conservés et leur justification ;
• la suppression du checkout et des clés SSH temporaires ;
• la destruction du trousseau temporaire utilisé pour signer ;
• le retrait des profils de provisioning et des certificats temporaires ;
• la destination des artefacts et leur durée de conservation ;
• le compte système qui possède les fichiers après la tâche.

Expérience à retenir : un nettoyage réussi dans le répertoire principal ne suffit pas si une commande écrit dans /tmp, dans le cache utilisateur ou dans un trousseau permanent. Les chemins réellement utilisés par Xcode, les scripts de signature et les outils de dépendances doivent être inclus dans le test.

Pour les projets audio, vidéo ou de design qui génèrent de gros fichiers intermédiaires, l’équipe doit distinguer les caches nécessaires à la durée d’une tâche des données qui peuvent survivre entre deux projets. Un cache utile à la compilation n’est pas automatiquement acceptable pour des secrets ou des sources propriétaires. Cette distinction doit être documentée avant l’activation du pilote.

Un nœud qui reprend les tâches après un redémarrage contrôlé n’est pas nécessairement résilient à une interruption de processus ou à une coupure réseau brève. La validation doit donc séparer plusieurs événements : redémarrage distant du Mac, arrêt anormal du processus Runner, interruption réseau et dépassement de la durée autorisée d’une tâche.

Pour chaque événement, le responsable relève :

• la tâche en cours et son état dans CircleCI ;
• la possibilité ou non d’une reprise ;
• l’existence d’une exécution en double ;
• l’action requise pour remettre le nœud en service ;
• la présence d’un artefact partiel ;
• le délai d’intervention humaine, sans le transformer en promesse de performance ;
• la décision de publier, d’annuler ou de relancer.

Une publication ne doit jamais être déclarée sûre si une interruption peut déclencher deux opérations concurrentes sur le même environnement de signature. Les tâches de référence doivent donc inclure un scénario d’échec contrôlé, sans utiliser de certificat de production, puis confirmer que le système ne produit pas de faux succès.

Le redémarrage automatique doit être vérifié sur le mécanisme de service réellement installé, et non sur une session graphique ouverte par un administrateur. La documentation CircleCI relative à l’installation de Machine Runner 3 sur macOS doit être comparée à l’état observé sur le pilote. Si le comportement local diffère de la documentation, le nœud reste en « limitation de déploiement » jusqu’à clarification.

La décision peut être prise avec les conditions suivantes, à inscrire dans le dossier de changement :

• Si le service unique démarre, reprend après redémarrage, reçoit uniquement les projets autorisés, nettoie les fichiers et protège les éléments de signature, alors le pilote peut recevoir un périmètre de production limité.
• Si la tâche de référence réussit mais que le nettoyage, le routage ou le retour après incident n’est pas démontré, alors le nœud reste en essai et les tâches de publication restent sur une cible approuvée.
• Si l’ancien service et Machine Runner 3 peuvent tous deux accepter des tâches, alors la migration est refusée jusqu’à suppression de l’ambiguïté de démarrage.
• Si un projet non autorisé atteint la classe de ressource macOS, alors le jeton et les règles de routage doivent être révoqués ou corrigés avant toute nouvelle exécution.
• Si une interruption peut provoquer une double publication ou laisser une signature réutilisable, alors le nœud revient à l’état précédent ou bascule vers le secours documenté.
• Si la capacité fixe ne suffit pas pendant les périodes de publication, alors l’entreprise doit étudier un second nœud isolé ou une capacité Mac distante temporaire plutôt que surcharger le pilote.

Le rapport final ne devrait pas se limiter à « Runner en ligne » ou « build réussi ». Il doit classer chaque domaine en approuvé, déploiement limité ou retour aux corrections, avec un propriétaire et une preuve pour chaque exception. Cette structure aide également à planifier la capacité d’un parc de Mac sans confondre disponibilité du service et aptitude à publier.

Pour les équipes qui souhaitent tester un nœud séparé sans immobiliser leur Mac principal, les environnements Mac distants de NUKCLOUD peuvent servir de cible d’essai à évaluer selon les exigences de réseau, d’accès et de sécurité du projet. La décision doit rester fondée sur les preuves de la chaîne réelle, pas sur la seule disponibilité d’une console distante.

Un Mac acheté et conservé sur site reste pertinent lorsque l’entreprise possède déjà les procédures de maintenance, exige des interfaces physiques spécifiques ou exécute une charge lourde et stable pendant une longue période. Il faut toutefois intégrer le remplacement matériel, les mises à jour, l’accès physique, la capacité de secours et le temps d’intervention dans le TCO, au lieu de comparer uniquement le prix d’achat.

À l’inverse, un Mac distant loué peut convenir à un pilote isolé, à une montée de capacité lors d’une phase de publication ou à une équipe distribuée qui ne veut pas acheter une machine pour chaque développeur. Le coût exact dépend de la période et de la configuration choisies ; aucune estimation chiffrée ne doit être reprise sans tarif vérifié. Les modalités disponibles peuvent être étudiées sur la page française de commande NUKCLOUD, puis confrontées aux besoins de réseau privé, de stockage et de contrôle d’accès.

Cette comparaison ne transforme pas la location en solution universelle. Une organisation qui doit brancher un périphérique propriétaire, conserver un secret dans un module matériel local ou garantir une charge permanente peut préférer un Mac dédié. En revanche, modifier l’unique machine de publication pour tester une migration reste une mauvaise pratique, quel que soit le mode de possession.

Le dossier d’acceptation doit réunir la configuration retenue, l’identité du nœud, les journaux d’installation, les résultats de la tâche de référence, les règles de routage, les tests de nettoyage et les observations de redémarrage. Les secrets eux-mêmes ne doivent jamais être copiés dans ce dossier ; seules leur présence contrôlée, leur rotation et leur destruction peuvent être attestées.

Avant le déploiement par lots, l’équipe peut appliquer cette séquence :

• approuver le périmètre du pilote et son responsable ;
• retirer l’ancien service sans laisser deux mécanismes concurrents ;
• installer Machine Runner 3 selon la documentation officielle ;
• comparer le fichier de configuration et les hypothèses d’exécution ;
• tester un projet autorisé et un projet refusé ;
• vérifier l’effacement du code et des éléments de signature ;
• exécuter les scénarios de redémarrage, d’arrêt et de réseau ;
• décider entre déploiement limité, correction ou retour arrière ;
• basculer les nœuds restants un par un, avec une preuve comparable ;
• revoir la capacité après observation des files d’attente et des échecs réels.

Pour une équipe qui dépend de la signature iOS, le seuil d’acceptation doit être plus exigeant que pour une simple compilation de test. Pour une équipe de production audio, vidéo ou design, la même logique s’applique aux fichiers volumineux et aux bibliothèques propriétaires : l’environnement doit être reproductible sans laisser les actifs d’un projet accessible au suivant.

La migration CircleCI Machine Runner 3 sur macOS est donc acceptable lorsque le service, le routage, les permissions, le nettoyage et la récupération sont démontrés ensemble. Si l’un de ces domaines reste hypothétique, l’entreprise doit conserver le nœud actuel ou utiliser un nœud de secours, plutôt que d’appeler « validée » une migration fondée sur un seul voyant vert.

Si le Mac actuel cumule les rôles de production, de test et de secours, ses défauts sont structurels : il constitue un point unique de panne, mélange plusieurs niveaux de confiance et rend le retour arrière dépendant d’une intervention urgente. Dans ce cas, louer chez NUKCLOUD un Mac distant séparé pour le pilote offre une voie plus prudente : l’équipe conserve son nœud existant, exécute les vraies vérifications de routage et de nettoyage, puis décide du nombre de nœuds permanents à partir de la file d’attente et des exigences de publication. Ce choix ne remplace pas l’audit de sécurité ni la validation CircleCI ; il évite surtout de transformer la seule machine de livraison en laboratoire de migration.