如何用 2 台 Cloud Mac 支撐 Flutter 團隊 CI？

VPSSpark Cloud Mac CI 系列 #9。本篇回答 Flutter 團隊常被問到的問題：8～15 人的團隊，能不能用 2 台 Cloud Mac 把 CI 跑穩？ 答案是可以——前提是把 Android 與 iOS 分開看：Android 構建留在 GitHub 託管的 ubuntu-latest，macOS 側用兩台自託管 Runner 分成 macos-fast 與 macos-archive 兩個池，並嚴守「PR 不跑 Archive」這條鐵律。下文提供負載模型、Job 分層、workflow 片段與落地清單；排隊診斷與 Runner 註冊細節分別見系列 #2 與 併網 FAQ。

1 · 反直覺結論：Flutter CI 的瓶頸不在 Dart

Flutter 跨平台優勢容易讓人誤以為「一條 workflow 打天下」。實務上，flutter analyze 與單元測試在 Linux 也能跑；真正必須 macOS 的，是 CocoaPods 解析、Xcode 編譯、簽章與 IPA 匯出。若 PR 路徑混進 Archive Job，一台 Cloud Mac 會被 25～40 分鐘的 iOS 打包占滿，其餘 PR 全部 Queued——和原生 iOS 團隊踩過的坑一模一樣，診斷公式仍是 wait time >> run time（詳見 macOS runner queued 診斷）。

因此「2 台 Cloud Mac」不是「2 台萬能機」，而是刻意設計的雙池拓撲：一台專職快回饋，一台專職發版重任務。Android APK/AAB 繼續走託管 Linux，不把寶貴的 macOS 槽位浪費在 Gradle 上。

2 · 負載模型：8～15 人團隊需要多少 macOS 並行？

以中等活躍度的 Flutter 團隊為基準（每人每天 1～2 次 PR，主分支 nightly + 每週發版）：

快池（macos-fast）單次 Job 目標：analyze + 單測 + iOS 模擬器構建，wall time 控制在 8～14 分鐘（有 pub/DerivedData 快取）。Archive 池（macos-archive）上的 Release IPA + 公證，單次 20～35 分鐘，但頻率低——main 合併、tag、定時 nightly 才觸發。兩台機器若混池，Archive 會把 fast 池堵死；分開後，PR 的 P95 等待時間通常能壓在 10 分鐘以內，對 Flutter 團隊的 code review 節奏已經夠用。

若團隊超過 15 人、或 monorepo 裡 matrix 拆多 flavor，才需要考慮第三台 Archive 冗餘或彈性擴容——那屬於 大規模 iOS CI 容量設計 的決策，不是本篇「2 台起步」要解決的問題。

3 · Flutter Job 三層：對齊 CI Hard Rules

把 Flutter 流水線映射到系列通用的 L0/L1/L2 分層，便於和 on-call 手冊對齊：

三條鐵律與原生 iOS 相同：Rule 1 PR 不得跑 L2；Rule 2 L2 必須在隔離池；Rule 3 fast 池不得被 Archive 阻塞。Flutter 特有的一點：L0 裡大量步驟其實可以在 Linux 完成——若你把它也綁到 macos-fast，會白白消耗 macOS 並行；建議 PR 上 Linux Job 與 macOS Job 並行，macOS 只跑「非 Mac 不可」的步驟。

4 · 雙機拓撲：Cloud Mac #1 與 #2 怎麼分工

Cloud Mac #1（快池）：註冊 label [self-hosted, macOS, macos-fast, flutter]。預裝固定版本的 Flutter SDK（用 fvm 或映像內 pin 版本）、Xcode、CocoaPods。Runner 以常駐服務方式執行，開機自啟；這台機器可以較積極地保留 pub cache 與 DerivedData，因為 Job 短、周轉快。

Cloud Mac #2（Archive 池）：label [self-hosted, macOS, macos-archive, flutter-release]。與快池實體隔離——不要在同一台 Mac 上掛兩個 pool 的 Runner，否則 Rule 2 形同虛設。Archive 機存放 Distribution 憑證與 App Store Connect API Key（用 Keychain + 最小權限 token，註冊步驟見 30～60 分鐘併網清單）。發版前可在這台機上跑 flutter doctor -v 與一次 dry-run Archive，避免污染快池環境。

兩台機器建議同區域、同 Xcode 大版本，減少「快池綠、Archive 紅」的版本漂移。Cloud Mac 相對辦公室 Mac 的優勢是：映像規格固定、到 GitHub 的網路穩定、無需維護 UPS 與實體安全——適合作為 7×24 的 CI 節點。關於自託管 Runner 的安全邊界，務必把 Archive 機權限收窄到單一 repo 或單一 org。

5 · Workflow 範例：PR 與 main 分流

下面片段展示核心分流邏輯（完整 pipeline 還需快取、密鑰與 artifact 步驟）。Flutter 官方持續交付文件對 iOS 簽章有詳細說明，此處假設憑證已匯入 Archive 機 Keychain。

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 / 公证 — L2 only

注意 ios-pr-fast 裡沒有 build ipa。若產品要求在 PR 上驗證真機包，應改為手動 workflow_dispatch 觸發、且仍走 Archive 池——而不是預設 PR 事件。GitHub Actions 的workflow 語法裡，用 concurrency 群組把同一 PR 的舊 run 取消掉，能再省約 20% 的無效排隊。

6 · 快取清單：Flutter 團隊最該 persist 的四類目錄

2 台 Cloud Mac 要跑穩，快取比 CPU 型號更關鍵。建議在 Runner 使用者目錄持久化（或 nightly 快照）：

• PUB_CACHE / ~/.pub-cache — Dart 相依；換 pubspec.lock 時增量更新
• Flutter SDK 目錄 — 用 fvm 固定版本，避免 flutter upgrade 漂移
• ios/Pods + CocoaPods 下載快取 — pod install 是 iOS 側常見長尾
• Xcode DerivedData — 對同一 ios/Podfile.lock 命中率高時效益明顯

快池與 Archive 池不要共用同一份 DerivedData 目錄——Debug/Simulator 與 Release/Archive 的編譯產物混寫會導致詭異的連結錯誤。Android 側的 Gradle cache 留在 ubuntu-latest 上用 Actions Cache 即可，無需占用 Cloud Mac 磁碟。

7 · 落地清單：從 0 到雙機併網

按順序執行，可在 1～2 個工作天內完成 PoC：

• 開通 2 台同規格 Cloud Mac（建議 M4 + 16GB 起，iOS 編譯記憶體峰值常見 12GB+）
• #1 裝 Flutter/Xcode/CocoaPods，註冊 macos-fast Runner；#2 額外匯入簽章材料，註冊 macos-archive
• 拆分 workflow：Android 留 ubuntu-latest；PR macOS 僅 L1；main/tag 才 L2
• 設定 pub/DerivedData/Pods 持久化；觀察 3 天 P95 wait time 是否 < 10 min
• 若 wait >> run 仍成立，先查 workflow 是否 L2 進 PR，再加機器

PoC 階段可以只買一台 Cloud Mac 跑快池，Archive 暫時用 GitHub 託管 macos-latest（接受排隊）——驗證分池邏輯後再補第二台。這與「2 台起步」不矛盾：第二台是發版 SLA 的保險，不是 PR 回饋的必需品。

8 · FAQ