Lorsque plusieurs dépôts multiplient les xcodebuild sur une même flotte, le mode d'échec est rarement le CPU seul. En 2026, les surprises douloureuses restent les DerivedData partagés, les caches Swift Package Manager trop étroitement ou trop largement clés, et les écritures en rafale pendant l'édition de liens, l'indexation et la préparation d'archives qui aplatissent les files SSD. Cette note façon FAQ sépare les caches chauds à chemin fixe des bacs à sable éphémères par job, détaille les ingrédients de clé de cache qui survivent aux mises à jour de chaîne d'outils, compare les politiques de nettoyage sous concurrence et juxtapose les formes courantes de pools de ressources d'entreprise. Pour le dimensionnement d'un pool et la réutilisation des caches, partez de
2026 — Pool CI Mac en entreprise : parallélisme multi-dépôts, cache, disque — cloud ou auto-hébergé ?
puis reliez quotas runners, alertes disque et rétention d'artefacts à
2026 — Multi-runners Mac auto-hébergés & CI parallèle : cache GitHub Actions, disque persistant, concurrence, disques pleins et nettoyage d'artefacts — FAQ pool d'entreprise.
1. DerivedData : racine fixe contre isolement par job
Un DerivedData global unique sous ~/Library/Developer/Xcode/DerivedData est le moyen le plus rapide d'obtenir une corruption mystérieuse entre jobs lorsque deux pipelines compilent le même graphe de modules avec des drapeaux de compilateur différents. Le défaut plus sûr pour une CI parallèle est un répertoire parent stable sur SSD rapide plus un dossier enfant clé par slug de dépôt, branche et identifiant d'exécution, exposé via DERIVED_DATA_PATH ou -derivedDataPath. Les équipes qui tiennent à un chemin fixe pour la vitesse incrémentale doivent tout de même garantir l'unicité au moins par hachage de WORKSPACE et numéro de build Xcode afin que deux jobs n'écrivent jamais dans le même magasin d'index en concurrence. Documentez le contrat de rétention : tout ce qui vit sous le préfixe par exécution est jetable après succès, tandis que les caches partagés longue durée appartiennent à des volumes majoritairement en lecture avec des règles de promotion explicites.
2. Clés de cache SwiftPM : ce qui doit entrer dans l'empreinte
Les caches SwiftPM distants et locaux ne se comportent correctement que si les clés incluent l'identifiant de build Xcode, la version du compilateur Swift, la somme de contrôle de Package.resolved et la tranche de plateforme de destination (simulateur iOS contre appareil, architecture macOS). Omettre la tranche Xcode restaure des artefacts compilés avec des modules clang incompatibles ; omettre le fichier de verrouillage réutilise silencieusement des résolutions de graphe qui ne correspondent plus à Package.swift. Pour les monorepos qui embarquent des binaires, ajoutez un hachage du manifeste binaire afin que les XCFrameworks précompilés ne traversent pas les versions d'OS. Gardez une racine canonique SourcePackages par classe de machine, mais conditionnez les restaurations avec la même granularité de clés que pour DerivedData afin que des jobs parallèles ne se décompressent pas dans le même checkout mutable.
3. Pics disque lorsque xcodebuild s'exécute en concurrence
Même avec des clés parfaites, des jobs qui se chevauchent créent une superposition d'E/S : Swift émet de gros fichiers temporaires pendant l'optimisation module entier, le fractionnement des symboles de débogage duplique des données, et xcodebuild archive met en scène des bundles pendant que codesign réécrit des segments Mach-O. Attendez-vous aux pires pics lorsque deux grosses applications lient simultanément sur le même volume : le débit s'effondre bien avant que le CPU n'atteigne cent pour cent. Les atténuations incluent des volumes APFS séparés pour le scratch et le système, des plafonds de concurrence par étiquette d'hôte, et le décalage entre archives et jobs de tests unitaires. Si vous automatisez des démons qui élaguent les caches entre les vagues, alignez-les sur des calendriers launchd ou des crochets d'orchestrateur, en veillant à ne pas chevaucher les phases sensibles de signature ou d'archivage.
4. Stratégies de nettoyage : balayages TTL, grands nettoyages nocturnes et budgets LRU
Les dossiers TTL par job suppriment les espaces de travail juste après l'envoi des artefacts, ce qui est le plus sûr pour les secrets mais sacrifie les artefacts incrémentaux chauds. Les grands nettoyages nocturnes récupèrent l'espace de façon prévisible mais laissent la journée exposée aux pics de croissance, associez-les donc à des seuils d'avertissement sur l'espace libre. Les budgets LRU par famille de cache (SwiftPM, CocoaPods, runtimes simulateur) plafonnent les octets totaux et expulsent les entrées les plus anciennes lorsqu'une nouvelle restauration dépasserait le quota — excellent pour les pools aux dépôts variés, mais plus difficile à auditer sans journaliser chaque chemin d'éviction. Les équipes réglementées combinent souvent des espaces TTL avec une reconstruction vérifiée hebdomadaire depuis un cache froid pour prouver la reproductibilité. Quelle que soit la politique, publiez-la à côté de la version d'image du runner pour que les développeurs comprennent pourquoi le build chaud d'hier a disparu.
5. Modèles de pool d'entreprise : nœuds dédiés, pools élastiques partagés et routage hybride
Les nœuds dédiés par ligne de produit maximisent la localité des caches et simplifient les périmètres de conformité, mais ils consomment de la capacité lorsque le trafic est irrégulier. Les pools élastiques partagés améliorent l'utilisation mais exigent un isolement strict des répertoires et une éviction automatisée ; sinon l'explosion DerivedData d'une équipe affame tout le monde. Le routage hybride envoie les trains de release et les grosses archives vers du matériel épinglé pendant que les branches de fonctionnalités flottent sur un pool général — plus lourd en exploitation, souvent le moins cher à grande échelle. Choisissez selon la variance de profondeur de file et le coût d'une purge transversale, pas seulement selon le prix affiché par heure de vCPU.
6. Checklist FAQ pour les équipes plateforme
- Chaque job concurrent dispose-t-il de sa propre feuille DerivedData sous une racine documentée ?
- Les clés de restauration SwiftPM incluent-elles build Xcode + fichier de verrouillage + destination ?
- Les alarmes disque sont-elles câblées avant que les étapes de liaison n'échouent avec des erreurs de compilateur trompeuses ?
- Le nettoyage est-il idempotent et sûr si deux tâches de maintenance se chevauchent après un déploiement ?
- La direction financière voit-elle l'utilisation du pool aux côtés de la sortie d'artefacts pour justifier des fragments dédiés ?
Pourquoi des nœuds Mac mini Apple Silicon collent à cette histoire disque
Un NVMe rapide et une large bande passante mémoire comptent davantage que le nombre de cœurs annoncé lorsque xcodebuild lie en parallèle. Les Mac mini sur Apple Silicon offrent les deux tout en consommant très peu au repos, ce qui rend les flottes CI toujours allumées moins chères la nuit que de nombreuses tours. macOS s'intègre proprement aux attentes de Xcode pour les chemins, les services simulateur et le codesigning, et la pile sécurité d'Apple — Gatekeeper, SIP et FileVault — donne aux équipes plateforme un récit plus simple pour les comptes de build sans surveillance que la plupart des bricolages inter-hyperviseurs.
Si vous standardisez la prochaine vague d'hôtes de build, associez ces politiques disque à du matériel qui ne bride pas les performances sous une E/S soutenue. Le Mac mini M4 reste un compromis pratique pour les pools multi-dépôts qui exigent des performances prévisibles par unité de rack. Pour une capacité Mac cloud dédiée sans long cycle d'achat, ouvrez la page d'accueil Macstripe afin de comparer régions et modèles à votre empreinte de concurrence et de conformité — c'est aussi le moment idéal pour envisager un Mac mini M4 neuf si vous voulez aligner votre labo local sur la même discipline disque que vos runners.
