Sommaire
Trois douleurs récurrentes quand la collaboration partage un builder
Sans file, verrous et timeouts explicites, la latence cache des courses réelles.
- 1Concurrence implicite sur clone ou cache partagé — symptômes « toolchain » en réalité coordination.
- 2File sans plafond — saturation perçue comme panne ; il faut rejeter vite avec message de retry.
- 3Timeouts décoratifs — jobs et verrous retenus des heures ; borne obligatoire.
FAQ : quand le sériel strict bat la concurrence limitée ?
Sériel strict : au plus un pipeline lourd sur état mutable partagé (archive Xcode, vague de tests Simulateur, écriture dans un cache commun). La latence monte quand la file grossit, mais vous supprimez des courses subtiles et des artefacts incohérents. Concurrence limitée — typiquement deux tâches légères — n’est défendable qu’avec worktrees isolés, chemins de sortie disjoints et surveillance CPU/RAM ; dès que deux jobs partagent encore CocoaPods, npm global ou une session graphique, le parallélisme produit des incidents difficiles à reproduire.
Règle d’onboarding : sériel pour lourd + cache partagé ; n’augmentez le parallélisme que si CPU soutenu reste sous ~75 %, la RAM libre dépasse ~8 à 16 Go après macOS, et chaque job a son arbre. Le détail lockfile et worktree : matrice Git worktree et verrous CocoaPods/npm.
FAQ : comment poser flock sur un Mac builder partagé ?
flock pose des verrous consultatifs : tous les acteurs doivent jouer le jeu ; ce n’est ni une sandbox ni une preuve de sécurité. Nommez un fichier de verrou par ressource logique — par exemple pods-shared.lock pour un cache Pods partagé, simulator-ui.lock pour une seule suite UI à la fois. flock -n chemin.lock -- commande échoue immédiatement si la ressource est prise (la CI peut retenter ailleurs). flock -w 180 chemin.lock -- commande attend au plus trois minutes sur une étape courte (résolution deps, écriture cache). Évitez d’emballer toute une compilation dans le verrou. Même cartographie répertoires / verrous que pour la promotion d’artefacts : matrice rsync, NFS et cache partagé.
FAQ : profondeur de file, timeout de job, timeout d’attente de verrou
Profondeur : plafonner à ~20 jobs en attente (global ou par couloir release/PR) puis échec explicite avec consigne de retry ou autre label.
Timeouts job (à caler sur p95 + marge) : léger 15–25 min ; standard 35–60 min ; archive 45–90 min. flock -w toujours plus court que le timeout job — minutes, pas heures : sinon alerte « job ou section critique bloqué ».
FAQ : stabilité du nœud, verrous coincés et gestion des conflits
Surveiller attente médiane, p95 attente verrou, disque, swap. Alertes si attente médiane > ~15 min (journée ouvrée) ou espace libre < 15 % ou 40 Go. Conflit : annuler job, vérifier aucun PID vivant, puis seulement retirer le .lock ; journaliser runner, commit, chemin. Long terme : pools interactif/CI séparés, nœud UI tests, ou second builder avant d’augmenter la concurrence YAML.
Ne pas confondre transport et verrous : FAQ stabilité, latence et SLA.
Matrice décision : sériel garanti contre concurrence contrôlée
| Critère | Sériel strict | Concurrence limitée |
|---|---|---|
| État partagé | 1 writer | Cache namespacé ou flock / domaine |
| Latence | Haute, prévisible | Basse si isolation + marge CPU/RAM |
| Simulateur | 1 flux UI | Nœud dédié ou simulator-ui.lock |
| Exploitation | Moins de mystères | Métriques et runbooks |
Feuille de paramètres exécutables (à coller dans le runbook)
| Paramètre | Valeur de départ | Note |
|---|---|---|
| Sériel build lourd | 1 / cache ou Simulateur GUI | + concurrence si worktrees OK |
| Jobs légers | ≤ 2 si CPU < ~75 %, RAM > ~8 Go | Stop si swap / E/S |
| File pending | ~20 | Refus explicite |
flock -n | Ressource occupée | Retry autre nœud |
flock -w | 120–300 / 30–60 s | Tune p95 attente |
| Timeout job | 15–25 / 35–60 / 45–90 min | p95 + marge |
| Alerte file | > 15 min médiane | Scale ou couloirs |
Cinq étapes pour industrialiser files, verrous et reprise
- 1Locks par ressource (Pods, npm, Simulateur), pas par équipe.
- 2Plafonds de file documentés + message CI explicite (retry / label).
- 3flock -w < timeout job ; alertes si timeouts verrou répétés.
- 4Pas de rm .lock sans vérifier PID ; tracer runner, commit, chemin.
- 5Revue hebdo : profondeur file, disque, DerivedData, scission couloir.
Synthèse et passage à l’échelle matérielle
Résumé : sériel sur état partagé, flock sur sections courtes, file bornée, timeouts mesurés. Concurrence = optimisation après isolation. Offres (sans compte), aide, accueil, blog.