Construire un pipeline CI/CD iOS sur des hôtes cloud Mac mini M4

Passé une certaine taille d'équipe, « sur quel poste le build passe-t-il vraiment » devient discrètement le goulot d'étranglement. Depuis que nous avons migré toute notre CI/CD iOS vers les hôtes cloud Mac mini M4 de Kvmzen, le temps d'attente des builds a nettement baissé et les incidents de signature ont quasiment disparu. Cet article détaille les pièges rencontrés en construisant ce pipeline depuis zéro, ainsi que le Fastfile et la stratégie de cache sur lesquels nous nous sommes finalement arrêtés.

Pourquoi un Mac mini M4 cloud pour la CI/CD

Un build Xcode est une tâche typiquement « gourmande en calcul et fortement liée à la version de l'OS », difficile à maintenir stable durablement sur un Runner local improvisé. Nous avons choisi des nœuds Mac cloud pour trois raisons principales :

• Spécification reproductible : l'image fige les versions d'Xcode et des outils en ligne de commande, si bien qu'une mise à jour silencieuse de l'OS ne peut jamais faire que seul le poste d'une personne compile encore.
• Capacité élastique : avant une release, les tests de non-régression peuvent démarrer temporairement plusieurs nœuds en parallèle, puis les libérer — pas besoin de réserver du matériel en permanence pour de rares pics.
• Disponibilité 24 h/24 : la faible consommation au repos de la puce M4 permet de faire tourner builds nocturnes et scans de sécurité planifiés en continu sans se soucier de la facture d'électricité ni du bruit.

Notre première erreur : traiter « l'hôte cloud » comme un simple écran distant et ne l'utiliser que pour du packaging manuel. Le vrai bénéfice n'est apparu qu'une fois branché sur la chaîne de déclenchement de la CI.

Conception du pipeline CI/CD

Découpage en étapes

Nous avons découpé un pipeline de release complet en quatre étapes :

1. Récupération du code et résolution des dépendances (SPM / CocoaPods)
2. Tests unitaires et analyse statique (exécutés en parallèle)
3. Archivage xcodebuild archive et signature
4. Envoi sur TestFlight et notification du canal d'astreinte

Hooks et conditions de déclenchement

Chaque fusion sur main déclenche automatiquement les étapes 1-2 ; les étapes 3-4 ne s'exécutent que lorsqu'un tag release/* est poussé, afin que les petits commits du quotidien ne consomment pas le quota de signature. Lors du débogage local d'une lane Fastlane, on interrompt généralement un run complet avec Ctrl+C pour ne relancer que l'étape en échec — cela économise un temps d'attente non négligeable.

Extrait de Fastfile

lane :ci_archive do
  cocoapods
  run_tests(scheme: "Kvmzen")
  build_app(
    scheme: "Kvmzen",
    export_method: "app-store",
    output_directory: "./build"
  )
  upload_to_testflight(skip_waiting_for_build_processing: true)
end

Ce script n'a rien de compliqué ; l'essentiel est qu'il produise le même résultat chaque fois qu'il tourne sur la même image de base — c'est précisément pour cela que nous consignons la version de l'image dans les logs de build, afin de savoir plus tard si un échec vient de l'environnement ou du code.

Cache et gestion des dépendances

Un cache mal configuré, et l'avantage de vitesse du build cloud est entièrement englouti par le temps de téléchargement des dépendances. Voici le comparatif établi après trois mois en production :

Quelques termes à clarifier d'abord :

DerivedData

Le répertoire de cache des artefacts de build incrémental d'Xcode ; sa réutilisation entre les builds réduit nettement les compilations suivantes.

Cache SPM

Le cache local des sources de paquets et des résultats de résolution du Swift Package Manager, évitant une nouvelle récupération distante à chaque build.

Image de base

L'instantané système prêt à l'emploi de l'hôte cloud, avec une version figée d'Xcode/CLT et un cache de dépendances préchauffé.

Diagnostiquer les problèmes courants

Le point le plus facile à manquer : un certificat expiré n'échoue pas immédiatement, mais seulement à la toute dernière étape, l'envoi vers TestFlight, après que tout le pipeline a déjà tourné à vide pendant une dizaine de minutes. Nous vérifions désormais la validité du certificat dès l'étape 1, pour échouer et alerter plus tôt.

Au début, nous utilisions une méthode brutale — « vider tout le cache et tout reconstruire chaque nuit » — pour éviter la corruption du cache. Nous sommes ensuite passés à une invalidation basée sur la version de l'image (réutilisation si la version ne change pas, purge uniquement lors d'une mise à niveau de l'image), ce qui préserve la vitesse sans laisser un cache corrompu provoquer des soucis pendant des semaines sans être détecté.

« Ne fais pas confiance à une seule CI verte ; fais confiance à dix CI vertes consécutives. » — une phrase répétée dans notre guide d'astreinte, particulièrement pendant les deux premières semaines après la migration vers un nouveau nœud cloud.

Questions fréquentes