從 GitHub Actions 遷移至自建 Mac 節點：開發效率提升了多少？（2026 實測對照）

Quick Answer：效率提升多少？

一句話：開發效率提升的主項是「等待」，不是「編譯器變快」。自建節點把稀缺 macOS 池從共享佇列裡摘出來，再疊持久化 DerivedData，才出現上表的量級。

先量什麼，再談「提升了多少」

很多團隊遷移後覺得「沒快多少」，是因為只看了 GitHub Actions 裡的 Job duration，忽略了 queue time 和人在 Slack 裡乾等的時間。建議遷移前後各採兩週，至少記四類數：

• 排隊等待：job queued 到 job started 的秒數，按 P50 / P95 彙報
• PR 回饋環：最後一次 push 到 required checks 全綠的時間
• 發版窗口吞吐：固定 4 小時窗口內成功上傳 TestFlight 的次數
• 被動等待人時：抽樣問開發者「今天等 CI 多久」或從 PR 評論時間戳推算

匯出方式：GitHub API 的 run_started_at 與 created_at 相減；或在 workflow 裡加一步把 queue 秒數寫入 artifact。沒有基線就遷，事後很難向管理層證明 ROI。

三套團隊對照：遷移前 vs 遷移後

下面三組數據均來自真實遷移專案（團隊名匿名化），條件已對齊：同一倉庫、同一 Xcode 大版本、採樣兩週工作日。

案例 A：12 人 iOS 團隊，單 App + 擴充功能

遷移前全部跑 macos-14 託管 runner；遷移後 2 台 M4 16GB Cloud Mac 自託管 Runner，DerivedData 掛本地 NVMe 路徑。PR 日均 18 次。

Tech Lead 原話：「以前下午五點 push，六點半才能知道能不能合；現在去倒杯水回來就綠了。」

案例 B：28 人 KMP + Android 主倉，Mac 只做 iOS 殼

遷移前 macOS Job 與 Android Job 搶同一發版窗口；遷移後 1 台常駐 M4 Pro + 發版週加 2 台 burst Cloud Mac（見 發版 burst 玩法）。

案例 C：8 人 indie，月發版 2 次

反例對照：他們遷移後幾乎沒提升——因為 PR 少、無排隊，自建機反而多了鑰匙圈維護。Archive 僅從 10.2 分鐘降到 9.4 分鐘（−8%），Queue 本就接近 0。這說明「提升多少」高度依賴負載形態，不能照搬大廠數據。

提升從哪來：排隊、快取、併發

把總等待時間拆開，更容易向非技術負責人解釋：

PR 總耗時 ≈ 排隊等待 + 環境準備 + 編譯測試 + 上傳製品

1. 排隊（最大頭）：GitHub 託管 macOS runner 是共享池，發版週、Xcode 大版本升級週 P95 排隊 30+ 分鐘不罕見。自建節點 = 獨佔執行器，queue 項幾乎消失。

2. 冷啟動與快取：託管 Job 結束即銷毀，DerivedData、Pods、SwiftPM 快取每次重來。自建機把熱目錄掛持久卷，二次建置常見快 20% 左右；細節見 自託管 Runner 快取與磁碟 FAQ。

3. 併發：2–3 台 Mac 並行接矩陣 Job，發版夜不再「一串糖葫蘆」排隊。注意多 Job 同機要寫目錄隔離，否則隨機失敗會把效率增益吃回去。

兩週遷移路徑：先對照，再切流量

不建議週五下班「一把梭」切生產。可複現的節奏如下：

• 第 1–2 天：從 Actions 匯出兩週 queue / duration 基線；選 1 台 Cloud Mac（約 5 分鐘開通）裝 Runner，runs-on: [self-hosted, macos, canary] 僅手動觸發
• 第 3–5 天：持久化 ~/ci/DerivedData 與 SwiftPM 快取；同一 main commit 跑 A/B 各 5 次，記 P50
• 第 6–8 天：Release / nightly workflow 切 50% 流量到自建 label；託管 runner 保留作 fallback
• 第 9–10 天：PR required checks 全切自建；寫磁碟 80% 水位與產物清理 cron
• 第 11–14 天：對照表複盤，向管理層報 ROI；決定常駐 1 台還是繼續按天租 burst

編排層仍用 GitHub Actions——YAML、權限、環境保護規則都不用換平台，只改 runs-on。這與 企業 Mac CI 資源池選型 裡的「編排與執行分離」是同一思路。

最小 Workflow 改動示例

jobs:
  ios-build:
    # 遷移前：runs-on: macos-14
  ios-build:
    runs-on: [self-hosted, macos, ios-pool]
    steps:
      - uses: actions/checkout@v4
      - name: Log queue metrics
        run: echo "QUEUE_SEC=${QUEUE_SEC:-0}" >> $GITHUB_STEP_SUMMARY

若你尚未決定買不買機器，按天租 M4 Cloud Mac 做兩週對照，成本通常低於「全組人多等一小時」的人力帳。

ROI 粗算：效率帳能不能蓋住機器帳？

用案例 A 的數字舉個可套用的公式（時薪按 blended $55 估，僅示意）：

• 12 人 × 每週少等 3.7 人時 ≈ 44 人時/月 ≈ $2,420/月 等價產出（或更早合 PR 減少衝突返工）
• 2 台 M4 16GB Cloud Mac 月租約 $206（$103/台 × 2，以定價頁為準）
• 平台兼職維運約 4–8 人時/月（磁碟、憑證、Runner 升級）

粗算淨收益仍為正——但小團隊低頻建置（案例 C）可能算不過來。決策前用你自己團隊的 queue P95 代入：

月收益 ≈ 開發者數 × 每週少等人時 × 4 × 時薪 − 機器月租 − 維運人時 × 時薪

發版週還可臨時加第三台機做 burst，平峰退租，避免全年為峰值買單。買 vs 租的長期 TCO 對照見 買 Mac mini 還是租 Cloud Mac。

什麼時候別遷？——避免為遷移而遷移

下列情況我會明確建議先別動，或只租一週做驗證：

• 月 macOS Job <30 次，且 Queue P95 長期 <5 分鐘——提升天花板很低（案例 C）
• 無人能 on-call 維護 Runner——磁碟打滿比排隊更搞心態
• 安全合規要求機器必須在自有 VPC——先解決網路與金鑰方案，再上自建池
• 以為遷完就不用 GitHub Actions 了——編排、審計、權限仍值得留在平台上

遷移是手段，目標是可測量的等待時間下降。兩週對照實驗做不出 >30% 的 PR 回饋改善，就該先優化 workflow（拆 Job、減 Archive 頻率），而不是先買三台 Mac。

常見問題 FAQ

從 GitHub Actions 遷到自建 Mac，開發效率一般能提升多少？

高頻 iOS 團隊常見 PR 回饋縮短 70% 左右、排隊接近歸零；純編譯快 15%–25%。低頻團隊可能只有個位數百分比——務必先採基線。

只加一台 Mac 夠嗎？

對 10 人以內、串行發版通常夠；若矩陣測試或多 App 並行，建議 2 台起，並設併發上限避免互踩快取。

自建後 Actions 帳單會降多少？

macOS 分鐘數往往可降 60%–90%（視你把多少 Job 遷走）；但會增加機器租購與維運。總帳要用上文 ROI 公式一起看。

Cloud Mac 和辦公室 Mac mini 效率有差嗎？

同晶片同記憶體下，編譯性能接近；差別在網路 RTT（拉依賴、上傳製品）與磁碟是否 NVMe。選離程式碼託管與製品庫近的節點。

遷移會影響簽章與公證嗎？

不會 magically 變好，但環境穩定後鑰匙圈與描述檔漂移減少，間接少了很多「只在 CI 復現」的半夜救火。

要多長時間才能看見提升？

Runner 接好且快取目錄生效後，第一個工作日就能在 queue 指標上看到變化；PR 回饋環建議採滿兩週再彙報。

總結與延伸閱讀

從 GitHub Actions 遷移至自建 Mac 節點，開發效率提升的答案不是模糊的「快很多」——在典型 iOS 團隊裡，PR 回饋縮短約七成、發版吞吐翻倍是常見量級，其中大頭是排隊消失，其次才是持久快取。用兩週對照實驗、四類指標和 ROI 公式，你可以給出老闆能聽懂的數字；若對照不明顯，先優化 workflow 比先買機器更划算。

• GitHub Actions 不給力，iOS 流水線新玩法
• 多 Mac 自託管 Runner：快取與磁碟 FAQ
• iOS CI 慢、GitHub Actions 排隊？Cloud Mac 入門
• 買 Mac mini 還是租 Cloud Mac
• 企業 Mac CI 資源池選型