Dieser Artikel tut eine Sache
- Das mentale Modell Flutter iOS CI = Steuerungsebene + Ausführungsebene + Cache-Ebene aufbauen.
- Eine macos-latest vs. Self-hosted-Entscheidungsmatrix liefern — in 5 Minuten entschieden.
- Die detaillierte Implementierung auf 5 Fachartikel verteilen — direkter Zugang nach Schmerzpunkt.
Das Drei-Ebenen-CI-Modell
Bevor wir uns konkrete Tools ansehen, eine Gleichung als Grundlage — sie bestimmt, welche Ebene angepasst werden muss:
Flutter iOS CI =
Steuerungsebene (GitHub Actions: Trigger · Genehmigungen · Secrets)
+ Ausführungsebene (Mac mini M4 : nativer iOS-Build · Signierung · Umgebungskonsistenz)
+ Cache-Ebene (Lokales SSD : persistente Deps und Build-Artefakte)Drei Korollare, die alle Entscheidungen dieser Serie leiten:
- Die Steuerungsebene führt keinen Code aus. Workflow-YAML zu optimieren beschleunigt Builds nicht. Buildminuten zu reduzieren erfordert das Ersetzen der Ausführungsebene.
- Die Ausführungsebene bestimmt die Reproduzierbarkeit. Die Xcode-Version im gemeinsam genutzten Pool (
macos-latest) folgt GitHub-Updates; bei Self-hosted legen Sie die Version fest. - Die Cache-Ebene bestimmt die Geschwindigkeit. Der Geschwindigkeitsvorteil von Self-hosted kommt nicht vom CPU, sondern davon, dass lokales SSD die pro-Job-Uploads/-Downloads aus dem Remote-Cache ersetzt.
Warum Flutter iOS CI eine dedizierte macOS-Ausführungsebene braucht
Flutter kann Android-Builds und Unit-Tests auf Linux verarbeiten, aber iOS-Builds und App-Store-Releases können nur auf macOS ausgeführt werden — eine harte Einschränkung der Apple-Toolchain, nicht von Flutter.
Jedes Flutter-Team steht daher vor einer Architekturentscheidung: Wo läuft der iOS-Zweig? Drei typische Reibungspunkte treiben Teams weg von macos-latest:
- Kosten: GitHub-gehostete macOS-Runner haben einen deutlich höheren Minutenpreis als Linux. iOS-Cold-Builds dauern häufig 20–30 Minuten; die Rechnung wächst schnell mit der Build-Frequenz.
- Umgebungskonsistenz: Die Xcode-Version in gehosteten Images folgt GitHub-Updates — sie kann nicht fixiert werden. „Lokal erfolgreich, CI schlägt fehl" wird zu einem wiederkehrenden Debugging-Aufwand.
- Build-Geschwindigkeit: iOS-Abhängigkeiten sind voluminös. Gehostete Runner laden den Cache bei jedem Job erneut hoch und herunter. Eine Self-hosted-Maschine mit lokalem SSD beseitigt diesen Engpass grundlegend.
„Die macOS-Ausführungsebene in eine kontrollierte Grenze zurückbringen" — das ist die zentrale Architekturentscheidung. Die Steuerungsebene bleibt in GitHub (PR-Trigger, Review-Gates, Secrets-Verwaltung); nur die Ausführungsschicht wird durch einen dedizierten Mac mini M4 ersetzt.
Offizielle Referenzen: GitHub Self-hosted Runner Dokumentation · Flutter CD-Leitfaden
Architekturübersicht
Die gesamte Pipeline auf das Drei-Ebenen-Modell abbilden — bei Problemen zuerst die Ebene identifizieren, dann zum entsprechenden Fachartikel gehen:
| Ebene | Zuständig für | Nicht zuständig für | Fehlersignale |
|---|---|---|---|
| Steuerungsebene | Trigger-Regeln, Berechtigungsgrenzen, Secrets-Injektion, Artefakt-Upload | Führt keinen Build-Code aus | Job nicht ausgelöst / Berechtigungsfehler / PR-Gate defekt |
| Ausführungsebene | Nativer iOS-Build, fixierte Xcode-Version, Signierungskette | Verwaltet nicht Trigger-Logik und Secrets-Quelle | Umgebungsdrift / Signierungsfehler / Runner offline |
| Cache-Ebene | Job-übergreifende Persistenz von Abhängigkeiten und Build-Artefakten | Bestimmt nicht Build-Trigger und Ausführungsumgebung | Hot-Build ≈ Cold-Build / Festplattenwarnung / zufällige Fehler |
Jeder Flutter iOS CI-Fehler lässt sich einer dieser drei Zeilen zuordnen. Die richtige Ebene identifizieren macht den Lösungsweg klar.
Entscheidungsmatrix: Wann lohnt sich die Migration?
Self-hosted ist nicht die Standardantwort. Diese Matrix ermöglicht eine Entscheidung in 5 Minuten im Team-Review:
| Signal | macos-latest behalten | Zu Self-hosted migrieren |
|---|---|---|
| Build-Frequenz | < 40 iOS-Builds pro Monat | > 40/Monat oder mehrmals täglich |
| Umgebungsstabilität | Nicht sensitiv gegenüber Xcode-Nebenversionen | Xcode/SDK-Version muss fixiert werden |
| Build-Geschwindigkeit | Hot-Build < 8 Min. akzeptabel | Hot-Build dauerhaft > 8 Min., verlangsamt Iteration |
| Release-Pipeline | Keine App-Store-Signierung erforderlich | App Store / TestFlight Release-Pipeline vorhanden |
| Betriebsbereitschaft | Zero-Ops bevorzugt | Bereit, monatliches Wartungsfenster gegen Kontrolle zu tauschen |
Faustformel: 3 oder mehr „migrieren"-Signale — Self-hosted amortisiert sich typischerweise in 2–4 Wochen (Maschinenmiete vs. eingesparte gehostete macOS-Minuten).
Themenserie: Direktzugang nach Schmerzpunkt
Dieser Artikel behandelt nur Architekturverständnis und Migrationsentscheidung. Jede Ausführungsschicht hat ihren dedizierten Fachartikel:
| Thema | Kernfrage | Ebene | Link |
|---|---|---|---|
| ① Runner-Einrichtung | Wie Mac mini stabil online, planbar und sicher isoliert halten | Ausführung | Demnächst verfügbar |
| ② Drei-Schichten-Cache-Modell | Warum iOS-Builds nicht schneller werden und wie lokales SSD hilft | Cache | Demnächst verfügbar |
| ③ Signierung & Release | Wie iOS-Signierung und App-Store-Upload in unbeaufsichtigtem CI abgeschlossen werden | Ausführung | Demnächst verfügbar |
| ④ Workflow-Design | Wie Android/iOS-Aufteilung, Pfad-Filterung und Nebenläufigkeit gestaltet werden | Steuerung | Demnächst verfügbar |
| ⑤ Betrieb & Stabilität | Warum CI ausfällt, Runner-Wiederherstellung nach Ausfall, Festplattenmanagement | Ausführung + Cache | Demnächst verfügbar |
Einstiegspunkt nach Szenario wählen
- Von Grund auf aufbauen: Dieser Artikel zur Architekturrichtung → ① „Runner-Einrichtung" für die Maschine → ② „Cache-Modell" zur Geschwindigkeitsoptimierung → ③ „Signierung" für die Release-Pipeline.
- Runner vorhanden, aber iOS-Build langsam: Direkt zu ② „Drei-Schichten-Cache-Modell".
- Signierung oder TestFlight blockiert: Zu ③ „Signierung & Release".
- Runner offline / Builds zufällig fehlerhaft: Zu ⑤ „Betrieb & Stabilität".
- Migration von Bitrise oder anderem Cloud-CI: Kostenvergleichstabelle in Bitrise vs. Self-hosted Cloud Mac Entscheidungsleitfaden.
Benötigen Sie einen Mac mini für diese Architektur?
kvmboot bietet tenant-dedizierte Mac mini M4 (16 GB / 24 GB), per SSH/VNC bereitgestellt, tages-, wochen- oder monatsweise abgerechnet. Ihre Steuerungsebene bleibt in GitHub; nur die Ausführungsebene wird durch diese Maschine ersetzt. Mit dem Drei-Ebenen-Modell dieses Artikels ist das typische Schema: Tag 0 Provisionierung, Tag 1 CI-Pipeline-Verbindung, Tag 2 Signierungsvalidierung — mit konsistenter Xcode-Version ab dem ersten Build.
Spezifikationen und Tarife: Tarife ansehen · Konfigurationsoptionen