Reichen zwei Cloud Macs für Flutter-Team-CI?

VPSSpark Cloud Mac CI Serie #9. Eine Frage aus DACH-Flutter-Teams kommt ständig: Kann ein Team mit 8–15 Leuten die CI mit zwei Cloud Macs stabil betreiben? Ja — wenn Android und iOS getrennt gedacht werden: Android-Builds bleiben auf dem GitHub-gehosteten ubuntu-latest, auf macOS laufen zwei Self-hosted Runner in den Pools macos-fast und macos-archive, und die harte Regel gilt: kein Archive auf PR. Im Folgenden: Lastmodell, Job-Schichten, Workflow-Snippet und Go-live-Checkliste. Warteschlangen-Diagnose und Runner-Anbindung finden Sie in Serie #2 sowie im Praxisbericht drei Cloud Macs für hohes iOS-CI-Volumen.

1 · Überraschende Erkenntnis: Der Flutter-CI-Engpass liegt nicht bei Dart

Cross-Platform suggeriert oft „ein Workflow für alles“. In der Praxis laufen flutter analyze und Unit-Tests auch auf Linux; macOS brauchen Sie für CocoaPods, Xcode-Compile, Signing und IPA-Export. Mischt ein Archive-Job in den PR-Pfad, blockiert ein Cloud Mac 25–40 Minuten — alle anderen PRs stehen auf Queued. Das kennen native iOS-Teams; die Diagnose bleibt wait time >> run time (siehe macOS-Runner-Warteschlangen-Diagnose).

Zwei Cloud Macs sind daher keine „zwei Universal-Maschinen“, sondern eine bewusst getrennte Zwei-Pool-Topologie: eine für schnelles Feedback, eine für Release-Schwere. APK/AAB bleiben auf Linux — macOS-Slots nicht für Gradle verbrennen.

2 · Lastmodell: Wie viel macOS-Parallelität braucht ein 8–15-Personen-Team?

Als Referenz ein mittelaktives Flutter-Team (1–2 PRs pro Person und Tag, nightly auf main, wöchentliche Releases):

Im Fast-Pool (macos-fast): analyze, Tests, iOS-Simulator-Build — Ziel 8–14 Minuten Wall Time mit pub-/DerivedData-Cache. Im Archive-Pool (macos-archive): Release-IPA plus Notarisierung — 20–35 Minuten, aber selten (main, Tags, nightly). Gemischte Pools lassen Archive den Fast-Pool verstopfen; getrennt bleibt die P95-Wartezeit für PRs meist unter 10 Minuten — ausreichend für Code-Review-Rhythmus in Berlin, München oder Zürich.

Ab 15+ Leuten oder vielen Matrix-Flavors im Monorepo lohnt eine dritte Archive-Redundanz — Kapazitätsplanung wie im 500-Builds/Tag-Szenario, nicht Gegenstand dieses Zwei-Maschinen-Starts.

3 · Drei Flutter-Job-Ebenen: CI Hard Rules

Flutter-Pipeline auf L0/L1/L2 mappen — passend zum On-call-Handbuch:

Drei Regeln wie bei nativem iOS: Rule 1 PR ohne L2; Rule 2 L2 nur im isolierten Pool; Rule 3 Fast-Pool darf nicht durch Archive blockiert werden. Flutter-spezifisch: vieles in L0 läuft auf Linux — wer alles an macos-fast bindet, verschwendet macOS-Kapazität. PR: Linux- und macOS-Jobs parallel; macOS nur für „nicht auf Linux machbar“.

4 · Zwei-Maschinen-Topologie: Aufgaben von Cloud Mac #1 und #2

Cloud Mac #1 (Fast-Pool): Labels [self-hosted, macOS, macos-fast, flutter]. Flutter SDK fixiert (fvm oder Image-Pin), Xcode, CocoaPods. Runner als Dauer-Service mit Autostart; pub cache und DerivedData aggressiv warm halten — kurze Jobs, hoher Durchsatz.

Cloud Mac #2 (Archive-Pool): Labels [self-hosted, macOS, macos-archive, flutter-release]. Physisch getrennt — nie zwei Pool-Runner auf einem Mac (sonst ist Rule 2 wirkungslos). Distribution-Zertifikate und App Store Connect API Key im Keychain; Anbindungsschritte analog Runner-Onboarding in der Praxis. Vor Release: flutter doctor -v und Dry-run-Archive — Fast-Pool nicht kontaminieren.

Gleiche Region, gleiche Xcode-Hauptversion — weniger „Fast grün, Archive rot“. Cloud Mac: festes Image, stabile GitHub-Anbindung, kein Büro-UPS — gut für 7×24-CI. Zur Sicherheitsgrenze Self-hosted Runner: Archive-Maschine auf ein Repo oder eine Org beschränken.

5 · Workflow-Beispiel: PR und main getrennt

Kern der Aufteilung (vollständige Pipeline braucht noch Cache, Secrets, Artifacts). Flutter-CD-Dokumentation zu iOS-Signing; Zertifikate im Archive-Keychain vorausgesetzt.

jobs:
                  android-pr:
                    if: github.event_name == 'pull_request'
                    runs-on: ubuntu-latest
                    steps:
                      - run: flutter analyze && flutter test
                      - run: flutter build appbundle --release

                  ios-pr-fast:
                    if: github.event_name == 'pull_request'
                    runs-on: [self-hosted, macOS, macos-fast, flutter]
                    steps:
                      - run: flutter analyze
                      - run: flutter test
                      - run: flutter build ios --simulator --no-codesign

                  ios-release:
                    if: github.ref == 'refs/heads/main' || startsWith(github.ref, 'refs/tags/v')
                    runs-on: [self-hosted, macOS, macos-archive, flutter-release]
                    steps:
                      - run: flutter build ipa --export-options-plist=ExportOptions.plist
                      # TestFlight / Notarisierung — nur L2

In ios-pr-fast fehlt bewusst build ipa. Geräte-Build auf PR: nur per workflow_dispatch, weiterhin Archive-Pool — nicht als Standard-PR-Event. Mit concurrency in der Workflow-Syntax alte PR-Runs abbrechen — oft ~20 % weniger sinnlose Wartezeit.

6 · Cache-Checkliste: vier Verzeichnisse für Flutter-Teams

Zwei Cloud Macs laufen stabiler mit gutem Cache als mit der neuesten CPU. Im Runner-Home persistieren (oder nightly Snapshot):

• PUB_CACHE / ~/.pub-cache — Dart-Deps; bei pubspec.lock-Wechsel inkrementell
• Flutter-SDK-Verzeichnis — fvm pinnt Version; kein flutter upgrade in CI
• ios/Pods + CocoaPods-Cache — pod install ist oft der iOS-Schwanz
• Xcode DerivedData — hoher Nutzen bei gleichem ios/Podfile.lock

Fast- und Archive-Pool kein gemeinsames DerivedData — Debug/Simulator und Release/Archive vermischen erzeugt Linker-Geisterfehler. Gradle-Cache für Android auf ubuntu-latest via Actions Cache; Cloud-Mac-Disk schonen.

7 · Go-live: von null auf Zwei-Maschinen-Anbindung

In 1–2 Werktagen PoC-fähig:

• 2 gleich spezifizierte Cloud Macs (M4 + 16 GB empfohlen; iOS-Compile-Spitzen oft 12 GB+)
• #1: Flutter/Xcode/CocoaPods, Runner macos-fast; #2: Signing-Material, Runner macos-archive
• Workflows splitten: Android ubuntu-latest; PR nur L1; main/tag L2
• pub/DerivedData/Pods persistieren; 3 Tage P95 wait < 10 min beobachten
• Bleibt wait >> run: zuerst L2 in PRs prüfen, dann Maschinen addieren

PoC mit einer Cloud Mac für Fast-Pool; Archive vorübergehend auf gehostetem macos-latest (Wartezeit akzeptieren) — Logik validieren, dann zweite Maschine für Release-SLA. Widerspricht nicht „zwei Maschinen“: die zweite sichert Releases, nicht PR-Feedback.

8 · FAQ