2026 — Gouvernance mondiale des caches de build iOS : Derived Data Xcode et caches de dépendances — autorité monorégion ou nœuds Mac physiques régionaux ?
Les équipes iOS internationales hésitent entre « un cache autoritaire et une sync inter-régions » et « caches locaux sur Mac physiques dans chaque région ». Cet article aligne latence, cohérence et coût sur des seuils signables : deux matrices, un runbook en sept étapes, extraits rsync et variables d'environnement prêts à coller, et une FAQ.
Qui souffre et pourquoi : Lorsque des équipes mondiales réutilisent le Derived Data Xcode et les caches SPM/CocoaPods entre CI et Mac physiques distants, les tirages de cache transocéaniques gonflent le P95 des durées de build, tandis qu'un décalage de cache provoque des erreurs de linkage sporadiques. Enseignement : Ne liez pas les caches de dépendances à faible rotation (lecture seule) à la même politique de réplication que le Derived Data à forte rotation ; utilisez des matrices à seuils pour choisir entre autorité monorégion et colocalisation régionale. Ce que vous obtenez : deux tableaux, sept étapes de déploiement, commandes copiables, FAQ.
1. Freins et douleurs
- Coût caché : tempêtes de petits fichiers : le Derived Data contient une multitude de fichiers minuscules et d'index. Un rsync inter-régions ou le listage de métadonnées côté objet dépasse souvent le débit utile : les jobs s'empilent en « restauration de cache » au lieu de compiler lentement.
- La cohérence prime sur le « dernier état » : mélanger versions patch Xcode, toolchains Swift, caches de modules et index produit des échecs incrémentaux aléatoires. Il faut des clés adressées par contenu auditables — pas un vague « build d'hier soir ». Pour des bases RTT transfrontalières, voir la matrice SLO 2026 — Mac physique multirégions : RTT, gigue et perte de paquets ; pour la latence côté CI et le cache Actions, le guide runners macOS, étape « Set up job », cache et miroirs.
- Permissions et conformité : la concentration monorégion rapproche empreintes de sources et artefacts dans un seul compartiment. Avec des Mac physiques par région, définissez quels répertoires peuvent quitter une juridiction et lesquels doivent rester sur disque local audité — évitez de synchroniser des binaires intermédiaires vers des partages sans chaîne de possession.
2. Derived Data et caches de dépendances : autorité monorégion vs Mac physiques régionaux
Le tableau ci-dessous tranche d'abord sur l'indépendance des builds par région et la part du temps job consacrée à la restauration de cache (seuils d'ordre de grandeur ajustables selon la taille du dépôt).
| Dimension | Autorité monorégion + réplication asynchrone | Cache local sur Mac physique par région (colocalisé) |
|---|---|---|
| Cas d'usage idéal | Une région primaire de build ; les autres exécutent < 3 builds/jour et tolèrent des démarrages à froid de 15 à 45 min | Chaque région exécute ≥ 5 intégrations ou builds complets/jour, ou la restauration de cache dépasse ~25 % de la durée du job |
| Hypothèses réseau | Réplication sur liaison privée ou backbone cloud homogène ; copies massives inter-régions en fenêtres de maintenance | Builders dans la région avec Git et artefacts ; le Derived Data n'est jamais sur un chemin chaud transocéanique |
| Derived Data | Conserver des snapshots « dorés » pour les autres régions ; compartiments stricts par version Xcode exacte | Répertoire inscriptible indépendant par région ; pas de réutilisation de liens durs entre versions patch Xcode |
| SPM / CocoaPods | Stockage objet + CDN en lecture seule ; découpler du Derived Data | Volume régional monté ou SSD local ; réconciliation périodique des sommes avec les registres amont |
| Risques principaux | Un mauvais snapshot empoisonne toutes les régions ; factures de bande passante inter-régions | Dérive des dispositions disque et des politiques de rétention par région ; automatiser l'éviction |
3. Collaboration transfrontalière : matrice latence × cohérence
Tracez le RTT Git et artefacts contre le taux d'incidents cache (échecs non déterministes attribuables au cache par semaine ÷ builds totaux) pour des revues rapides.
| Taux d'incidents cache < 0,5 % | Taux d'incidents cache ≥ 0,5 % | |
|---|---|---|
| P95 RTT régional vers Git < 80 ms | Privilégier la colocalisation : Derived Data local + cache de dépendances in-region | Corriger d'abord l'espace de clés : compartiments par version Xcode exacte et branche, puis colocaliser |
| P95 RTT ≥ 80 ms ou pertes intermittentes | Autoriser un cache de dépendances autoritaire monorégion + jeux minimaux critiques pour la compilation hors région | Interdire la sync Derived Data transocéanique à chaud ; passer à des rebuilds propres canary |
Ajoutez à votre document SLO : âge maximal d'entrée de cache dans le train de release en cours ; P95 entre fin de restauration cache et premier démarrage de compilation xcodebuild sous 90 s (dépôts moyens) ou 180 s (monorepos). En cas de dépassement, désactivez le cache distant pour ce label de job et forcez un build propre régional.
4. Runbook en sept étapes
- Inventaire des chemins : séparez
DerivedData, cache global SPM, cache CocoaPods et répertoires de frameworks binaires personnalisés. Seuls les arbres lecture seule adressés par contenu vont en stockage objet. - Définir les clés de cache : inclure au minimum version Xcode, version Swift, branche ou hachage du fichier de verrouillage, configuration (Debug/Release). Interdire un pointeur
latestunique pour tout le dépôt. - Choisir la région de build primaire : alignez-la sur le remote Git principal et le registre d'artefacts ; les autres régions ne synchronisent que les couches de dépendances ou acceptent des démarrages à froid plus longs.
- Job canary : ne promouvoir un nouveau compartiment de cache qu'après un build propre complet sur un Mac physique et des tests verts.
- Mesurer trois phases : instrumentez restauration, compilation et tests séparément. Si la restauration domine, corrigez la topologie avant d'ajouter du CPU.
- Invalidation : le jour de montée de version Xcode, retirez automatiquement les anciens compartiments ; conservez N−1 snapshots lecture seule 7 à 14 jours pour rollback.
- Livrable de signature : imprimez les deux matrices sur une page pour la couverture du runbook astreinte. Avant chaque changement de topologie de cache, relancez les sondes d'acceptation RTT/gigue régionales décrites dans l'article SLO Mac multirégion cité ci-dessus.
5. Checklist de paramètres de synchronisation (copier-coller)
À coller dans vos scripts après substitution des hôtes et chemins. Toujours simuler les suppressions en dry-run d'abord.
A. rsync : sync massive Derived Data (horodatages préservés ; utiliser les variantes --delete avec prudence)
Push vers volume régional (exemple) :
rsync -aH --numeric-ids --delete-delay \ --exclude 'ModuleCache.noindex/**' \ --exclude 'CompilationCache.noindex/**' \ --timeout=300 --contimeout=60 \ ~/Library/Developer/Xcode/DerivedData/ \ build@MAC-REGION.ENTREPRISE:/Volumes/BuildCache/DerivedData/
B. rsync : cache SPM lecture seule (omettre --delete pour ne pas supprimer les fichiers d'autres builders)
rsync -aH --numeric-ids --omit-dir-times \ ~/Library/Caches/org.swift.swiftpm/ \ s3proxy-local:/spm-ro/CLE/
C. Flux tarball cache CocoaPods (bande passante inter-régions coûteuse, obsolescence à l'heure acceptable)
tar --posix -cf - -C ~/Library/Caches/CocoaPods . \ | pigz -1 \ | ssh -o ServerAliveInterval=30 build@DISTANT 'pigz -d | tar -xf - -C /Volumes/Cache/CocoaPods'
D. Variables d'environnement (fragment modèle CI)
export DERIVED_DATA_PATH="/Volumes/BuildCache/DerivedData/${CACHE_KEY}"
export CLONED_SOURCE_PACKAGES_DIR_PATH="/Volumes/BuildCache/SPM/${CACHE_KEY}"
export COCOAPODS_CACHE_DIR="/Volumes/BuildCache/CocoaPods/${CACHE_KEY}"
# Avant xcodebuild : vérifier chemins inscriptibles et correspondance build Xcode ↔ CACHE_KEY
6. Synthèse
Seuils réutilisables (exemples) : ① Restauration cache > ~25 % du temps job → revue d'architecture. ② Défaillances liées au cache ≥ 0,5 % / semaine → gel de la sync Derived Data inter-régions. ③ Timeout rsync par job 300 s, timeout connexion 60 s. ④ Les clés incluent la version Xcode exacte. ⑤ Promotion pool-wide uniquement après build canary propre réussi.
Pas de solution universelle : les caches de dépendances veulent « loin, lent, lecture seule », tandis que le Derived Data veut « proche, rapide, jetable ». Scindez d'abord les compartiments ; le débat monorégion / multirégion se réduit ensuite à l'arithmétique de la bande passante et aux maths de SLO.
7. Faire tourner cette gouvernance sur Mac mini
Tous les chemins ci-dessus fonctionnent nativement sous macOS : Xcode, SwiftPM, SSD locaux et outillage Unix sans couche intermédiaire. Un Mac mini Apple Silicon combine une bande passante mémoire unifiée élevée avec une consommation au repos d'environ 4 W — idéal comme ancrage régional de cache 7j/7 qui préchauffe index et dépendances pendant que le parc est inactif. Les taux de plantage macOS restent faibles ; Gatekeeper, SIP et FileVault s'alignent proprement sur les revues sécurité par rapport à des hôtes de build génériques.
Si vous voulez que chaque zone géographique termine restauration plus compilation dans un RTT local au lieu de traîner le Derived Data en archives transocéaniques, standardiser des pools Mac mini par région est le format le plus discret — compact, souvent sans ventilateur ou très silencieux, et moins coûteux en énergie et en attention opérationnelle sur plusieurs années.
Lorsque vous passez de « ça compile quelque part » à « nous pouvons signer un SLO », le Mac mini M4 est l'un des meilleurs rapports prix/stabilité pour des nœuds de build homogènes — louez ou montez en charge des Mac physiques régionaux dès maintenant et ancrez la politique de cache sur des disques et réseaux réels.
8. FAQ
Le Derived Data doit-il vivre dans une seule région ou sur chaque Mac physique régional ?
Si les builds tournent surtout dans une région et que les autres ne font que valider légèrement, utilisez une autorité monorégion avec réplication asynchrone. Si chaque région exécute des builds complets quotidiens et que le RTT Git ou artefacts transocéanique domine, colocalisez un Derived Data inscriptible sur des Mac physiques régionaux et gardez la résolution des dépendances in-region.
Quels seuils de cohérence comptent le plus ?
Exemples exploitables en signature : âge maximal de cache dans le train de release, accord sur clé ou somme de contrôle, jamais de partage de chemins Derived Data entre versions patch Xcode, taux d'échec de résolution SPM, part de démarrages à froid. Au-delà du seuil, préférez un rebuild régional propre à une sync incrémentale inter-régions.
SPM et CocoaPods doivent-ils suivre la même politique que le Derived Data ?
Non. Les dépendances conviennent au stockage adressé par contenu en lecture seule ; le Derived Data est sortie de build et index. Gardez les dépendances sur objet ou volume partagé lecture seule et le Derived Data inscriptible par région.
Quel est le plus grand risque d'une concentration monorégion ?
Bande passante inter-régions, latence de longue traîne sur de grandes arborescences, et une mauvaise sync qui empoisonne plusieurs régions. Atténuer avec vérification par blocs, compartiments par branche et builds canary avant promotion.
Builds iOS sur Mac physiques multirégions ?
Colocalisez les nœuds avec Git et les artefacts pour réduire la latence de restauration Derived Data et dépendances — pools Xcode et bureaux distants à la demande.