Sommaire
Public cible et mots-clés
À qui s’adresse cet article : les équipes d’environ 3 à 12 personnes qui partagent un ou plusieurs Mac distants pour l’iOS, le macOS ou une CI multi-plateforme, avec sessions SSH/VNC et jobs automatisés. Vous cherchez une collaboration équitable, un pool de ressources prévisible et une stabilité quand deux pipelines écrivent sur le même disque.
Mots-clés cœur (SEO) : Mac distant, Git worktree, builds parallèles, fichier de verrouillage / lockfile, conflit, pool partagé, DerivedData, CocoaPods, npm, profondeur de file, rollback.
Les douleurs typiques : couplage caché (deux jobs sur le même dossier Pods ou cache npm global), décalage de branche (lockfile sale sur l’hôte), saturation disque/Simulateur quand la concurrence n’est pas plafonnée. Ancrez ces règles avec la FAQ pool Mac partagé : files, quotas et conflits pour des seuils file/quotas alignés.
Git worktree et « un dépôt, plusieurs espaces de travail » : tableau comparatif
Les worktrees Git ajoutent plusieurs répertoires de travail attachés au même dépôt Git (une base d’objets partagée). L’alternative fréquente est d’avoir plusieurs clones complets du même dépôt — chacun avec son propre .git. Le tableau ci-dessous aide à trancher sur un Mac distant chargé de builds parallèles.
| Critère | Worktrees Git | Plusieurs clones complets |
|---|---|---|
| Disque (objets Git) | .git partagé ; moins de duplication. | Un magasin d’objets par clone ; modèle mental simple. |
| Sûreté en parallèle | Forte si chaque worktree a son répertoire de build et préfixe de dépendances dédiés. | Forte si les chemins ne se chevauchent jamais ; fragile si les scripts supposent une racine fixe. |
| Charge ops | Hygiène git worktree add/remove/prune obligatoire. | Plus lisible pour les débutants ; plus de dossiers abandonnés à purger. |
| Défaut recommandé | Mac distant partagé avec beaucoup de builds PR courts. | Voies produit longues, remotes ou identifiants très différents. |
En résumé : les worktrees optimisent le ressource pool disque tout en permettant des branches concurrentes ; ils exigent une convention de nommage (/builds/<repo>/wt-<branche>) et des scripts qui n’écrivent jamais hors du préfixe du job.
CocoaPods, npm et stratégie des fichiers de verrouillage
Les fichiers de verrouillage (Podfile.lock, package-lock.json, etc.) sont la source de vérité versionnée. Le Mac partagé ne doit pas les « réparer » silencieusement en CI : cela masque les conflits et pollue les autres branches.
- CocoaPods : exécutez
pod installavec--project-directorypointant vers le worktree, ou bac à sable explicite ; versionnezPodfile.lock; échouez la CI si le lock ne correspond pas au sommet de branche. - npm / pnpm / Yarn : privilégiez
npm ci(ou équivalent) dans chaque worktree ; figez Node via.nvmrcou Volta pour éviter les dérives entre jobs. - Caches : isolez cache npm ou CocoaPods par « lane » de pool si plusieurs apps sans lien partagent la machine ; sinon un cache unique avec mutex sur l’étape d’install réduit les courses.
Cette discipline renforce la stabilité des builds parallèles : chaque job part d’un état Git propre et d’installs reproductibles. Pour l’accès humain vs automation avant de durcir les scripts, voir le guide de choix SSH vs VNC pour petites équipes.
Plafond de concurrence et files d’attente
Sans plafond, les builds parallèles saturent RAM, SSD et Simulateur — et la collaboration souffre (SSH lent, VNC saccadée). Point de départ réaliste : 1 archive ou compilation lourde Xcode active par classe de Mac ; jusqu’à 2 contrôles légers seulement si le CPU soutenu reste sous ~75 % et la RAM libre au-dessus d’~8 Go après macOS.
Côté file, fixez une profondeur d’attente d’environ 20 jobs par pool avec échec explicite au-delà — mieux qu’une attente silencieuse de plusieurs heures. Étiquettes runner, priorités release vs PR et matrices de routage doivent refléter le matériel réel : croisez avec la matrice runner GitHub Actions auto-hébergé, routage et files pour aligner sémantique Git et capacité.
Matrice de décision et paramètres
Utilisez ce tableau comme aide rapide dans votre runbook interne ; les paramètres sont des ordres de grandeur à ajuster selon votre monitoring.
| Signal | Si vrai, privilégier | Paramètre indicatif |
|---|---|---|
| Nombreuses branches courtes / jour | Worktrees + prune automatique | ~8 worktrees ouverts max par hôte avant d’ajouter un nœud |
| Courses Pod / npm fréquentes | Répertoires d’install par worktree ou mutex d’install | 1 vol d’install à la fois par lane de pool |
| Archives release vs bruit PR | Hôtes ou créneaux séparés | Label release dédié, 0 workflow PR sur ce label |
| Pression disque | Purge DerivedData + arbres obsolètes | Nettoyage sous ~15–20 % d’espace libre |
Paramètres notables (runbook)
- Concurrence compilation lourde : démarrer à 1 job actif par classe de Mac.
- Tâches légères : jusqu’à 2 si marge CPU/RAM dans la bande ci-dessus.
- Alerte file : profondeur d’attente ~20 jobs / pool.
- Espace disque : action sous ~15–20 % libre (ou seuil Go minimal documenté).
FAQ : rollback, nettoyage et responsabilités
- Comment rouler arrière un worktree « empoisonné » ?
- Stoppez le job, supprimez le répertoire du worktree, exécutez
git worktree prune, effacez le sous-dossier DerivedData associé, puis relancez après un fetch propre. N’utilisez pasgit reset --hardsur le clone principal depuis un script opaque. - Quand purger les caches ?
- Après résolutions échouées, erreurs de signature liées à des pods obsolètes, ou lorsque les caches dépassent typiquement ~30–80 Go par palier — sans effacer en masse trousseaux et profils de provisionnement.
- Qui possède le nettoyage hebdomadaire sur le pool ?
- Désignez un responsable rotatif ; journalisez espace libre, worktrees ouverts et profondeur de file. Liez les alertes aux mêmes seuils que vos revues de stabilité.
Déploiement en cinq gestes
- 1Créez un dépôt nu ou clone canonique sur le Mac distant ; documentez le chemin.
- 2Standardisez les noms de worktrees et les préfixes de build par job.
- 3Branchez la CI pour créer/rafraîchir un worktree par job, puis installs lockfile-only.
- 4Échouez vite sur arbre Git sale ou lockfile divergent.
- 5Plafonnez la concurrence, alertez sur la file, planifiez prune + nettoyage disque.
Lorsque les worktrees et la collaboration dépassent la capacité d’un seul hôte, séparez les pools (PR / release) ou ajoutez un nœud — la stabilité du ressource pool prime sur le parallélisme maximal théorique.
Passez à plusieurs nœuds Mac lorsqu’un seul hôte ne suffit plus à vos worktrees
Meshmac propose des Mac distants avec SSH et VNC pour scinder pools PR et release, figer Xcode par machine et garder des builds parallèles prévisibles. Parcourez les offres et passez commande sans créer de compte sur la page dédiée : comparez les gammes, puis invitez l’équipe lorsque votre matrice de verrous et de concurrence est documentée. Retrouvez aussi le blog pour les guides multi-nœuds et l’accueil pour un aperçu rapide des services.
Les règles de cet article se branchent sur un fournisseur qui expose des nœuds réels et reproductibles : commencez par un Mac, mesurez attente en file et espace disque, puis dupliquez le modèle worktree+verrous sur un second nœud lorsque les seuils d’alerte se déclenchent trop souvent.