Ce guide s’adresse aux responsables de l’efficacité R&D qui maintiennent un dépôt contenant de nombreuses ressources Git LFS et dont l’étape de validation iOS CI devient instable ou lente.

Il concerne également les responsables IT qui doivent décider entre achat, migration, Mac distant ou capacité élastique, ainsi que les équipes sécurité chargées des jetons, des caches et de la reproductibilité des builds.

Un temps total de pipeline en hausse ne prouve pas que les performances de compilation du Mac ont diminué. Une extraction peut attendre le serveur LFS, télécharger des objets non nécessaires, reconstruire un répertoire de travail ou restaurer des dépendances avant même que Xcode ne commence.

Vous devez donc créer deux références avec exactement la même tâche :

• une exécution sans objet localement disponible, représentative d’un démarrage froid ;
• une exécution avec les objets et dépendances susceptibles d’être réutilisés, représentative d’un démarrage chaud.

Relevez dans les journaux le transfert Git classique, le téléchargement LFS, le remplissage du workspace, la restauration des dépendances, le temps d’attente en file et la compilation. Les journaux de transfert Git LFS et les traces du composant de validation doivent rester attachés à chaque mesure.

La règle de décision est simple :

• si l’attente réseau et le téléchargement LFS occupent l’essentiel du temps, augmenter la puissance du Mac ne traite pas la cause ;
• si le workspace est incomplet ou reconstruit inutilement, corrigez le périmètre et le cycle de vie du cache ;
• si la compilation reste durablement limitée par le processeur ou la mémoire après un checkout maîtrisé, évaluez de nouveaux nœuds.

Le mécanisme officiel distingue bien les pointeurs présents dans Git et les objets binaires stockés par Git LFS. Consultez la documentation officielle du fonctionnement de Git LFS avant d’interpréter un fichier de travail comme une ressource réellement téléchargée.

Cette séparation répond à une erreur fréquente : un fetch réussi signifie que les références ont été récupérées, pas que chaque fichier attendu par le workspace est déjà matérialisé. Le manuel de Git LFS fetch décrit cette distinction entre récupération d’objets et mise à disposition dans le répertoire de travail.

Un pointeur LFS est léger par rapport à l’objet binaire qu’il désigne. La présence du pointeur dans une branche ne signifie donc pas que le contenu volumineux est déjà disponible sur le nœud Mac. Le checkout, le pull et les opérations LFS doivent être analysés comme des actions différentes.

Commencez par établir l’inventaire des chemins LFS réellement utilisés par chaque type de tâche :

• validation d’une modification de code ;
• génération d’une archive de publication ;
• tests d’interface avec médias ;
• production audio ou vidéo ;
• tâches de design nécessitant des fichiers lourds ;
• intégration complète du dépôt.

Une validation de modification n’a pas forcément besoin des mêmes ressources qu’une archive finale. Si ces deux parcours partagent le même téléchargement complet, la première tâche paie le coût de la seconde.

Les filtres de chemin peuvent réduire ce périmètre. Git LFS documente les commandes include et exclude, tandis que la documentation officielle de Git clone rappelle que la profondeur, les branches et le contenu récupéré influencent le checkout. Vous devez toutefois reproduire le comportement dans un dépôt de test proche du dépôt réel. Le composant de validation peut appliquer sa propre logique aux sous-modules, au checkout partiel ou à LFS.

Après chaque changement, vérifiez les fichiers réellement présents, et non seulement l’absence d’erreur dans la commande. Un build qui réussit sans exercer un parcours média ne valide pas nécessairement la chaîne de publication.

Un Mac toujours disponible peut conserver des objets LFS et éviter certains téléchargements. Cela ne suffit pas à prouver qu’il est plus rentable qu’un nœud distant lancé à la demande. Vous devez mesurer les octets téléchargés, la proportion d’objets déjà présents, la durée après réutilisation et la croissance du disque.

Distinguez au minimum :

• le magasin d’objets LFS ;
• le workspace du job ;
• les dépendances de compilation ;
• le cache Xcode ;
• les artefacts produits.

Un cache d’objets partagé entre projets peut réduire le réseau, mais il élargit aussi le périmètre de confiance et la surface d’exposition. Un workspace persistant, lui, peut laisser des fichiers, des configurations ou des artefacts d’une tâche précédente. Ces deux sujets ne doivent pas être traités comme une seule fonction « cache ».

La documentation de mise en cache des dépendances insiste sur un point important pour une organisation : la réutilisation d’un cache doit être évaluée avec son périmètre de confiance, pas seulement avec son gain apparent de temps.

Pour un nœud durable, définissez une politique de nettoyage déclenchée par la croissance du disque, l’ancienneté des objets et le changement de projet. Pour un nœud élastique, prévoyez plutôt une couche de préparation contrôlée ou regroupez les tâches qui utilisent les mêmes ressources. Dans les deux cas, mesurez le résultat sur la pipeline iOS réelle, et non sur une copie artificiellement réduite du dépôt.

L’optimisation n’est valable que si elle conserve la même intégrité de sortie. Une tâche doit pouvoir prouver que les ressources attendues sont présentes et que le résultat ne dépend pas d’un fichier laissé par un job antérieur.

Ajoutez une validation reproductible :

• vérification des chemins LFS attendus ;
• contrôle des fichiers nécessaires au scénario média, audio ou vidéo ;
• comparaison avec une exécution propre ;
• contrôle des artefacts avant signature ou publication ;
• suppression ou reconstruction du workspace lorsque la preuve de complétude manque.

La gestion des identifiants mérite la même précision. Séparez le droit de télécharger le dépôt et les objets LFS du droit de signer ou de publier une application. Un jeton de lecture ne doit pas être traité comme une identité de production.

Les caches persistants et les espaces de travail durables doivent être classés selon le niveau de confiance de la branche. Une branche non vérifiée ne devrait pas hériter automatiquement d’un cache ou d’un jeton de publication. La documentation sur l’utilisation sécurisée des exécuteurs autogérés fournit le cadre à examiner avant de partager une machine entre des tâches de confiance différente.

Le composant qui prépare le checkout peut aussi modifier le comportement de LFS, du checkout partiel ou de la persistance des identifiants. La documentation du composant checkout doit être contrôlée pour la version effectivement déployée, puis comparée au comportement observé dans votre dépôt isolé.

Les avantages d’un cache partagé sont clairs :

• moins de transferts répétés ;
• meilleure utilisation d’un nœud durable ;
• diagnostic plus simple lorsque le périmètre est stable.

Ses inconvénients sont tout aussi concrets :

• exposition plus large entre projets ;
• nettoyage plus délicat ;
• risque de masquer une ressource absente ;
• dépendance à l’état local du nœud.

Si la chaîne ne peut pas démontrer la complétude du workspace, le gain de vitesse ne doit pas être accepté en production.

Après avoir réduit les téléchargements inutiles, examinez les métriques de capacité. Le nombre de développeurs n’est pas une méthode suffisante pour dimensionner des machines. Vous devez corréler le temps de build utile, l’arrivée des tâches, l’attente en file et la redondance nécessaire en cas de panne.

Trois leviers répondent à trois problèmes différents :

Un pool Mac fixe convient lorsque la charge est prévisible, que les certificats et l’environnement doivent rester contrôlés et que la réutilisation est suffisamment fréquente. Son avantage est la stabilité opérationnelle. Son défaut est de conserver une capacité même lorsque la demande baisse.

Un pool Mac distant élastique convient lorsque les pics sont irréguliers, que vous devez tester une capacité supplémentaire ou que l’achat d’équipements dédiés serait prématuré. Son défaut est le démarrage froid, la préparation de l’environnement et la nécessité de valider le réseau.

Un modèle hybride est préférable lorsque les publications critiques exigent un nœud fixe de confiance, tandis que les validations et les pics de file peuvent être confiés à une capacité distante. Pour explorer ce scénario, vous pouvez comparer les options de Mac distant de KVMNODE avec votre capacité locale, en conservant la même branche, les mêmes ressources LFS et la même procédure de validation.

Avant de modifier le budget, faites passer la chaîne dans une matrice d’acceptation. Chaque ligne doit contenir une preuve, un résultat et une action de repli.

Votre analyse TCO peut rester neutre et vérifiable :

TCO = trafic réseau + stockage + temps d’occupation des Mac + heures d’exploitation + impact des incidents.

Ne préremplissez pas cette formule avec un prix générique. Utilisez vos factures, vos journaux de durée, vos coûts de stockage et le coût interne de l’intervention. Pour une comparaison d’équipement, la page Mac mini de KVMNODE peut servir de point de départ commercial, mais elle ne remplace pas une mesure de votre dépôt et de votre chaîne CI.

Votre décision finale devrait appartenir à l’une de ces trois catégories :

• optimiser uniquement Git LFS, si le réseau, le périmètre ou le cache expliquent l’essentiel du temps ;
• augmenter la capacité Mac, si la compilation reste saturée après correction du checkout ;
• conserver un nœud fixe fiable et ajouter une capacité distante, si les publications nécessitent un environnement stable mais que les pics de validation sont variables.

Pourquoi Git LFS allonge-t-il progressivement les extractions ?

Une extraction peut télécharger des objets sans rapport avec la tâche, reconstruire un workspace froid ou attendre le stockage distant. La dégradation apparente du Mac peut donc être une dégradation du chemin de données. Mesurez séparément Git, LFS, le checkout, les dépendances et Xcode avant de conclure.

Peut-on télécharger seulement les fichiers LFS requis ?

Oui, lorsque les tâches sont suffisamment bien séparées. Les filtres de chemin permettent de limiter la récupération, mais vous devez vérifier les dépendances indirectes et le comportement du composant de checkout. Après filtrage, contrôlez les fichiers présents dans un workspace propre avant de valider la méthode.

Comment réutiliser un cache LFS sur un Mac autogéré ?

Conservez le magasin d’objets séparé du workspace, associez-le au bon projet et mesurez les octets réellement évités. Ajoutez une procédure de nettoyage et une vérification de complétude. La présence d’un objet dans le cache ne prouve pas que tous les fichiers nécessaires à la tâche sont disponibles.

Réseau ou machines Mac : que faut-il augmenter ?

Augmentez le réseau ou le cache lorsque l’attente de transfert domine. Ajoutez des Mac lorsque le build reste limité par le processeur ou la mémoire et que la file persiste après optimisation du checkout. Une mesure par phase évite de payer une capacité de compilation pour résoudre un problème LFS.

Une infrastructure locale peut offrir un contrôle direct, mais elle immobilise du matériel, exige une capacité de secours et laisse à votre équipe la maintenance, le stockage et l’isolation des espaces de travail. Un Mac distant mal préparé ne résout pas davantage un périmètre LFS excessif : il peut seulement déplacer l’attente vers un autre nœud.

Après vos mesures, un essai court avec KVMNODE permet de rejouer le même dépôt et la même pipeline en comparant démarrage froid, réutilisation du cache, compilation réelle, file de pointe et reprise. Cette approche est plus fiable qu’une décision fondée sur une fiche technique seule. Si la demande est irrégulière, la capacité distante peut absorber les pics sans transformer chaque augmentation temporaire de charge en achat permanent. Si la charge est stable et lourde, un parc fixe ou un modèle hybride restera peut-être plus cohérent avec votre TCO.

La règle à retenir est donc conditionnelle : ne louez pas un Mac pour masquer un checkout mal mesuré, mais ne dimensionnez pas non plus un parc supplémentaire avant d’avoir prouvé que la compilation, et non Git LFS, est devenue le goulot d’étranglement.