Cet article fait une chose
- Construire le modèle mental Flutter iOS CI = Plan de contrôle + Plan d'exécution + Plan de cache.
- Fournir une matrice de décision macos-latest vs. auto-hébergé — conclusion en 5 minutes.
- Distribuer l'implémentation détaillée vers 5 articles thématiques — accès direct selon votre problème.
Le modèle CI en trois plans
Avant de regarder un outil quelconque, établissons une équation — elle détermine quelle couche modifier :
Flutter iOS CI =
Plan de contrôle (GitHub Actions : déclencheurs · approbations · Secrets)
+ Plan d'exécution (Mac mini M4 : build iOS natif · signature · cohérence env)
+ Plan de cache (SSD local : persistance des dépendances et artefacts)Trois corollaires qui guident toutes les décisions de cette série :
- Le plan de contrôle n'exécute pas de code. Optimiser le YAML du workflow n'accélère pas les builds. Réduire les minutes de build implique de remplacer le plan d'exécution.
- Le plan d'exécution détermine la reproductibilité. La version Xcode d'un pool partagé (
macos-latest) suit les mises à jour GitHub ; sur une machine auto-hébergée, c'est vous qui la fixez. - Le plan de cache détermine la vitesse. L'avantage de vitesse de l'auto-hébergement ne vient pas du CPU, mais du SSD local qui remplace l'upload/download de cache distant à chaque job.
Pourquoi Flutter iOS CI nécessite un plan d'exécution macOS dédié
Flutter peut gérer les builds Android et les tests unitaires sur Linux, mais les builds iOS et les releases App Store ne peuvent s'exécuter que sur macOS — une contrainte imposée par la chaîne d'outils Apple, pas par Flutter.
Chaque équipe Flutter doit donc faire un choix architectural : où faire tourner le volet iOS ? Trois frictions communes poussent les équipes à quitter macos-latest :
- Coût : Le tarif à la minute des runners macOS hébergés par GitHub est nettement supérieur à Linux. Un build iOS à froid prend facilement 20 à 30 minutes ; la facture monte vite avec la fréquence des builds.
- Cohérence de l'environnement : La version Xcode de l'image hébergée suit les mises à jour GitHub — impossible de la figer. « Passe en local, échoue en CI » devient un coût de débogage récurrent.
- Vitesse de build : Les dépendances iOS sont volumineuses. Les runners hébergés ré-uploadent et re-téléchargent le cache à chaque job. Une machine auto-hébergée avec SSD local supprime ce goulot d'étranglement à la racine.
« Ramener le plan d'exécution macOS dans un périmètre contrôlé » — voilà la décision architecturale centrale. Le plan de contrôle reste dans GitHub (déclencheurs PR, revues, gestion des Secrets) ; seule la couche d'exécution est remplacée par un Mac mini M4 dédié au tenant.
Références officielles : Documentation GitHub runners auto-hébergés · Guide CD Flutter
Vue d'ensemble de l'architecture
Mappez tout le pipeline sur le modèle trois plans — en cas de problème, identifiez d'abord le plan concerné, puis allez dans l'article thématique correspondant :
| Plan | Responsabilités | Hors périmètre | Signaux de défaillance |
|---|---|---|---|
| Plan de contrôle | Règles de déclenchement, périmètre des permissions, injection de Secrets, upload d'artefacts | N'exécute aucun code de build | Job non déclenché / erreur de permission / gate PR cassé |
| Plan d'exécution | Build iOS natif, version Xcode fixée, chaîne de signature | Ne gère pas les déclencheurs ni la source des Secrets | Dérive d'environnement / échec de signature / runner hors ligne |
| Plan de cache | Persistance inter-jobs des dépendances et artefacts de build | Ne décide pas des déclencheurs ni de l'environnement d'exécution | Build à chaud ≈ build à froid / alerte disque / échecs aléatoires |
Tout incident Flutter iOS CI se retrouve dans l'une de ces trois lignes. Identifier le bon plan rend le chemin de résolution évident.
Matrice de décision : quand la migration vaut-elle le coup ?
L'auto-hébergement n'est pas la réponse par défaut. Cette matrice permet de trancher en 5 minutes en revue d'équipe :
| Signal | Conserver macos-latest | Migrer vers auto-hébergé |
|---|---|---|
| Fréquence des builds | < 40 builds iOS par mois | > 40/mois, ou plusieurs fois par jour |
| Stabilité de l'environnement | Pas de sensibilité aux versions mineures de Xcode | Besoin de fixer la version Xcode / SDK |
| Vitesse de build | Build à chaud < 8 min acceptable | Build à chaud continuellement > 8 min, ralentit l'itération |
| Pipeline de release | Pas de signature App Store requise | Pipeline App Store / TestFlight en place |
| Appétit pour les opérations | Zéro ops prioritaire | Accepte une fenêtre de maintenance mensuelle en échange du contrôle |
Règle empirique : 3 signaux « migrer » ou plus — l'auto-hébergé s'amortit généralement en 2 à 4 semaines (location machine vs. minutes macOS hébergées économisées).
Série thématique : accès direct selon le problème
Cet article couvre uniquement la compréhension de l'architecture et la décision de migration. Chaque couche d'exécution a son article thématique dédié :
| Thème | Question centrale traitée | Plan | Lien |
|---|---|---|---|
| ① Configuration du Runner | Comment maintenir un Mac mini en ligne, planifiable et isolé de façon sécurisée | Exécution | Bientôt disponible |
| ② Modèle de cache à trois couches | Pourquoi les builds iOS ne s'accélèrent pas, et comment utiliser le SSD local pour y remédier | Cache | Bientôt disponible |
| ③ Signature et release | Comment compléter la signature iOS et l'upload App Store en CI sans surveillance | Exécution | Bientôt disponible |
| ④ Conception du Workflow | Comment structurer la séparation Android/iOS, le filtrage par chemin et la concurrence | Contrôle | Bientôt disponible |
| ⑤ Ops & stabilité | Pourquoi la CI plante, comment récupérer d'un runner hors ligne, gestion du disque | Exécution + Cache | Bientôt disponible |
Choisir son point d'entrée selon le scénario
- Partir de zéro : Cet article pour confirmer la direction architecturale → ① « Configuration du Runner » pour mettre la machine en ligne → ② « Modèle de cache » pour optimiser la vitesse → ③ « Signature » pour connecter le pipeline de release.
- Runner en place, mais build iOS lent : Aller directement au thème ② « Modèle de cache à trois couches ».
- Signature ou TestFlight bloqué : Aller au thème ③ « Signature et release ».
- Runner hors ligne / builds aléatoirement en échec : Aller au thème ⑤ « Ops & stabilité ».
- Migration depuis Bitrise ou autre CI cloud : Voir Guide de décision Bitrise vs. Mac cloud auto-hébergé pour un tableau comparatif des coûts de migration.
Besoin d'un Mac mini pour faire tourner cette architecture ?
kvmboot propose des Mac mini M4 dédiés au tenant (16 Go / 24 Go), livrés en SSH/VNC, facturés à la journée, à la semaine ou au mois. Votre plan de contrôle reste dans GitHub ; seul le plan d'exécution est remplacé par cette machine. Avec le modèle trois plans de cet article, le schéma habituel est : Day 0 provisionnement, Day 1 connexion du pipeline CI, Day 2 validation de la signature — avec une version Xcode cohérente dès le premier build.
Spécifications et forfaits : Voir les forfaits · Options de configuration