團隊 iOS CI/CD 怎麼估算 Mac 打包機數量？2026 容量規劃

判斷：不要按開發者人數直接換算 Mac 打包機數量；先量度任務到達節奏、執行時間、並發峰值與可接受的排隊時間，再用代表性負載測試驗證容量。負載長期穩定的部分可規劃固定容量，短時尖峰則評估彈性補充。

適合正從零規劃 iOS CI/CD 容量的技術負責人，按團隊紀錄建立估算流程。
若現有 Mac runner 經常排隊，可用隊列與構建紀錄判斷是否需要擴容。
負責比較固定採購與彈性算力的決策者，可據此整理容量及成本核算資料。

團隊 iOS CI/CD 的 Mac 打包機數量估算

開發者人數只能描述團隊規模，無法直接說明某個時間點有多少任務同時需要 Mac。實際容量還受工作流種類、任務執行時間、觸發時間是否集中，以及失敗重試等因素影響。即使團隊人數沒有變動，發布週期、測試範圍或專案組合改變，也可能令隊列狀況不同。

先界定要解決的問題：是日常 PR 檢查等待太久、發布時歸檔任務集中，還是測試工作流與其他構建互相爭用 runner？若只看平均用量，短時間的高峰可能會被掩蓋；若只看最繁忙時段，又可能把少見尖峰誤當成全天候需求。

Xcode CI 工作不只包括編譯。Apple 的 Xcode Cloud 工作流動作說明涵蓋構建、測試、分析及歸檔等工作流動作；Xcode Cloud 工作流參考則說明工作流設定。這些資料可協助你拆分任務類型，但不能替代團隊自己的耗時與排隊紀錄。

Mac 打包機數量應按人數還是構建並發估算？

以構建並發及可接受排隊時間作為容量規劃的主要依據，再用開發者人數作為背景資訊。相同人數的團隊，若提交時間、工作流數量或測試範圍不同，對 Mac runner 的需求也可能不同；因此不宜套用固定的「每位開發者配一台」換算方式。

建立現有構建負載基線

如何用歷史構建紀錄估算 iOS CI 容量？

先從 CI 平台匯出近期構建記錄，並確認資料欄位足以重建任務由觸發到完成的過程。建議至少整理：

• 觸發時間、任務開始時間與結束時間，據此分辨排隊和實際執行時間。
• 任務類型，例如 PR 檢查、主分支構建、測試、分析或歸檔。
• 任務結果及失敗重試，避免把重試工作漏算，或將失敗導致的額外執行時間當成正常基線。
• 對應的專案、分支或工作流，方便找出集中觸發的來源。

Apple 的在持續整合工作流中構建 Swift 套件或使用該套件的應用程式說明可用來核對 CI 工作中的構建環節；Apple 的Xcode CI 環境變數參考則可協助你辨認工作流環境資訊。平台文件能說明工作流如何運作，實際任務耗時仍應以你自己的記錄為準。

把時間分開看。將工作日尖峰、發布窗口及日常時段分開檢視，並比較每類任務在這些時段的到達與完成情況。不要只用全期平均排隊時間作結論：平均值平穩，不代表高峰期間不會出現積壓。

留意：如果記錄沒有分開呈現排隊時間與執行時間，先補足這兩項觀測，再據此調整 runner 容量。否則你可能把任務本身變慢，誤判成 runner 數量不足。

由隊列需求映射到 Mac runner

整理基線後，定義團隊可接受的等待時間及需要優先處理的任務，再觀察尖峰時段有多少工作同時等待或執行。這會形成一組可測試的容量假設，而不是一個可套用到所有團隊的通用數量公式。

怎樣判斷可接受的構建等待時間？

按任務用途分別設定等待目標：例如，會阻塞程式碼審查的 PR 檢查，和不一定要即時完成的批次驗證，未必適合使用同一個等待標準。再以近期記錄檢查高峰期間的隊列是否超出目標，並確認發布窗口是否有額外工作集中進入。

如果等待超標只集中在特定工作流，先檢查任務觸發節奏、執行順序及工作流設定；若多種任務持續爭用 runner，才將增加可用容量列為候選方案。這樣能避免以增購掩蓋排程或任務拆分問題。

並發任務如何對應到可用 runner？

將可同時執行的任務需求，對照實際可接收工作的 Mac runner 數量及分組，並檢查 CI 平台的並發上限、標籤、佇列和倉庫存取權限。GitHub Actions 的自託管 runner 管理說明和工作流語法文件可作為 runner 註冊與工作流設定的例子；它們描述的是 GitHub Actions 的規則，不能直接推定其他 CI 平台具有相同排程及並發行為。

檢查時可逐項核對：

• 需要執行的工作流是否能派送到預期的 runner 標籤或群組。
• runner 是否受平台並發設定或工作流條件限制。
• 倉庫、憑證及工作流權限是否讓任務具備執行資格。
• 任務失敗後的重試或相依關係，是否令後續工作排隊。

如果工作流未能找到符合條件的 runner，單純增加機器不一定能解除等待；先確認派送設定及權限，再判斷是容量不足還是配置阻塞。

代表性負載驗證容量假設

不要只根據估算立即承諾固定容量。選出能代表日常需求及高峰工作流的構建與測試任務，在受控環境中執行，並記錄每項任務的排隊時間、執行時間、失敗情況及資源爭用。Apple 的設定首個 Xcode Cloud 工作流說明可協助核對工作流範圍；容量驗證仍要使用團隊實際採用的平台和任務。

測試時，將長期穩定負載與短時尖峰分開比較。若日常隊列符合團隊目標，但發布窗口偶爾超標，可先評估排程調整或短期補充容量；若不同時段都持續積壓，便要重新檢視常駐容量與工作流配置。每次變更後，使用相同類型的任務重新比較，避免把不同工作負載的結果混在一起。

排隊多久才需要增加 Mac runner，沒有適用於所有團隊的固定門檻。以你設定的服務目標為準：當代表性觀察顯示等待持續超標，且派送、權限與工作流設定已核實，再評估增加 runner；若只有單一工作流異常，先排查其任務設計和執行記錄。

持續復核與容量選擇

容量不是一次估算後便固定不變。當 Xcode 版本更新、測試矩陣擴大、專案數量改變，或任務執行時間出現漂移時，都應重新檢視負載基線。日常復核可追蹤隊列等待、任務執行時間、失敗與重試、尖峰時段，以及既定等待目標是否達成。

若需評估遠端 Mac 的穩定性，先核對服務的運作與連線條件，再比較你對隔離及存取控制的要求；SDKMac 的穩定性說明與資料私隱說明可供採購評估時參考。它們不應取代你對 CI 平台設定、憑證管理和實際負載的驗證。

在比較容量方案前，先以團隊資料填入實際成本項目，例如硬體採購與折舊、維護與管理工時、場地及電力、租用週期、閒置時間，以及高峰時段的額外用量。沒有實際報價和使用紀錄時，不應推算固定節省金額。

表內評分是依負載條件作出的決策提示，不是通用性能排名。固定容量仍需考慮維護與閒置；彈性方案則要確認可用配置、交付方式及工作流能否接入。若團隊長期執行大量穩定負載，採購自有 Mac 可能更符合管理與使用方式；若需求以可預測基線加短時高峰為主，則可評估租用是否適合作為補充，而非預設所有容量都應外移。

完成測量與驗證後，下一步不是先決定租幾台，而是把持續負載和尖峰需求分開，再核對可用 Mac 配置、租用週期及 CI 派送條件。若短時峰值令自有設備閒置成本偏高，可在核實適配條件後，查看 SDKMac 的可用節點，評估是否以租用遠端 Mac 補充彈性容量；長期穩定高負載或依賴實體介面的工作，則應先比較自有設備是否更合適。