2026 pools de builds Mac cloud dispatchables : sharding de jobs, affinité DerivedData et checklist SLO de files

1. Douleurs : habitudes mono-hôte, shards manquants, dérive d affinité, langage SLO désaligné

Passer d un Mac SSH unique à plusieurs nœuds CI déplace les pannes typiques du manque de CPU vers l absence de planification explicite et de politique de cache. Les grands espaces de travail Swift réagissent à la profondeur de file NVMe et à la localité du cache de modules ; sans modèle, la variance aléatoire devient partie prenante du rythme de release. Les fermes Linux ont appris cette leçon il y a longtemps, mais les chaînes Apple punissent bien plus sévèrement une racine DerivedData partagée que beaucoup de pipelines centrés GCC.

1. Réflexes SSH sur plusieurs hôtes : les ingénieurs se connectent encore à une machine préférée alors que l ordonnanceur place les jobs au hasard. Sans labels ni contrats de file, les journaux ne recollent jamais aux chemins physiques et les incidents ne se capitalisent pas.
2. Sharding absent donc parallélisme fictif : dix builds PR sur huit slots semblent parallèles mais partagent une seule racine DerivedData ou un volume d artefacts. Le linkage se sérialise sur disque et vous payez des timeouts sporadiques.
3. Dérive d affinité : des builds consécutifs sur la même branche tombent sur d autres partitions ou perdent des sous-dossiers de cache, les gains incrémentaux s effondrent et les migrations Xcode sont accusées à tort.
4. SLO qui ne regarde que le CPU : quand la finance compte des minutes et la plateforme des cases vertes, les comités de capacité tournent en rond. Part de file, variance de linkage et minutes gaspillées en retry doivent vivre sur le même écran.

2. Matrice : grain de shard, forme de file, politique disque

La matrice complète l article warm-cold sur affinité DerivedData et backoff Mac cloud ainsi que le comparatif minutes GitHub Actions et baseline Mac pour PR et nightly. Dans ces pages vous choisissez la couche runner ; ici vous décidez comment plusieurs Mac dédiés coopèrent au sein de votre propre flotte. Pour la facturation minute et la profondeur de files, réutilisez aussi matrice baseline, burst et billing du pool Mac. Servez-vous en comme artefact de design review : une axe de shard principal par file, la décision disque juste à côté, et le plafond de concurrence que vous défendrez quand la file explose en semaine de sortie.

Les lignes restent courtes pour glisser dans des slides. Ajoutez dans la marge vos chemins réels afin que l astreinte sache immédiatement quel slot monopolise quel SSD. Lorsque la direction produit doute encore de files séparées pour les matrices Simulator, superposez une semaine de profondeur de file et d espace libre issus de votre dernière release : si les pointes de linkage coïncident avec moins de vingt pour cent libres, la réponse est généralement oui malgré le coût checkout additionnel.

3. Affinité DerivedData et barrières anti-stampede

L’affinité n’est pas une superstition : c’est la probabilité élevée de réutiliser les caches modules. Donnez à chaque slot son DERIVED_DATA_PATH, séparez Archive des incréments légers, bloquez les nouveaux Archive lorsque l’espace libre passe sous environ quinze pour cent et poussez les événements vers le même canal Webhook que vos seuils dans observabilité CI pour files d’attente, disque et webhooks.

Le backoff suit la taxonomie d échec : moins de retries espacés pour le linkage afin d éviter les essaims sur disque chaud, échecs rapides côté compilation pour libérer les slots. Deux seuils de profondeur fonctionnent bien : le premier baisse seulement la concurrence, le second ouvre un ticket capacité avant la facture. Gardez CocoaPods aussi cloisonné que DerivedData : un cache Pods partagé paraît anodin jusqu à ce que plusieurs jobs réécrivent des manifestes et noient le système de fichiers de petites écritures synchrones.

4. Cinq étapes jusqu à une triple confirmation

1. Profiler les jobs : séparez incréments froids, pipelines simulateur et Archive, mesurez parts file, compilation, linkage et upload. Si la part linkage décolle, inspectez une racine DerivedData partagée avant d acheter des cœurs.
2. Contrats de chemin : documentez JOB_SLOT, labels self-hosted et cartes de répertoires dans les modèles de dépôt, interdisez aux branches expérimentales d écrire dans des caches partagés pour éviter les fuites de secrets.
3. Gates de concurrence : maintenez Archive entre un et deux en parallèle global, montez les plafonds PR avec backoff exponentiel, placez les matrices simulateur sur une file dédiée pour éviter les collisions de linkage NVMe.
4. Cabler l observabilité : amenez profondeur de file, pourcentage disque libre et ratio minutes retry dans les mêmes panneaux que vos clusters d échecs pour que les timeouts de linkage répétés ouvrent des tickets infra par défaut.
5. Triple exécution : choisissez un commit, lancez-le trois fois, comparez P95 et clusters ; si la variance persiste, ajoutez un second hôte baseline bas débit avant de saturer un seul Mac.

5. Trois métriques faciles à citer

Elles voyagent dans les synthèses exécutives car elles traduisent la physique de file en budget sans se cacher derrière des cases vertes.

• Part de file sur le temps de bout en bout : au-delà d environ quinze pour cent corrélée au débit de commits, corrigez shard ou gate avant d accuser la vitesse d horloge.
• Variance de linkage : si les P95 diffèrent de plus d environ vingt-cinq pour cent sur trois runs identiques, suspectez DerivedData partagé, seuils d espace libre et files Archive mélangées.
• Ratio minutes retry : lorsqu il dépasse un quart du total, réduisez la concurrence et resserrez les plafonds avant d ajouter des nœuds.

Lorsque les trois se dégradent ensemble, traitez l incident comme capacitaire même si le taux de succès reste élevé : vous brûlez du budget en bruit infrastructure.

6. Lecture croisée warm path et routage élastique

Le routage élastique tranche quels jobs quittent les minutes hébergées pour des labels bare metal. Le warm path règle le comportement interne de chaque hôte. Ce texte couvre la coopération multi-hôtes : le sharding rend le parallélisme réel, l affinité rend les incréments fiables, le vocabulaire SLO aligne finance et plateforme.

7. FAQ

Question : deux nœuds suffisent-ils ? Réponse : oui avec contrats, sinon ce sont deux SSH qui partagent la douleur.

Question : schéma ou tests d abord ? Réponse : selon ce qui domine entre stampede et queue, Archive toujours isolé.

Question : cache distant distribué immédiat ? Réponse : rarement avant partitions NVMe locales et chemins par job ; sinon cohérence et egress compliquent tout.

8. Synthèse

Un pool dispatchable transforme plusieurs Mac en capacité programmable : le sharding définit si le parallélisme est honnête, l affinité si les incréments méritent confiance, les métriques SLO si les revues d échelle sont reproductibles. Lire files et disques ensemble fait passer le triage du tirage au sort des machines à l explication des paramètres.

Compter uniquement sur des pools hébergés partagés laisse la géométrie disque et les plafonds de concurrence dictés par le fournisseur, ce qui empêche de traiter macOS comme un terrain pleinement maîtrisé. Empiler de petits nœuds sans sharding ni affinité recrée le même stampede de linkage entre Archive et pull requests, gonflant queue et retries ensemble. Les équipes qui veulent une livraison iOS stable tout en gardant les habitudes SSH et launchd héritées des VPS Linux gagnent généralement à louer des nœuds Mac cloud Apple Silicon chez VPSMAC, placer les chaînes de linkage lourdes sur des baselines dédiées ou peu concurrentes, et encoder shards plus observabilité dans les gabarits de pipeline au lieu de partager une seule racine DerivedData pour chaque job.