以獨享 Mac mini 執行 Mac CI 叢集

唯一重要的數字，是最忙的那一小時內必須同時執行多少個建置。不是開發人員數，也不是儲存庫數，而是同時建置數。

適用於多數 iOS 團隊的大致規模：

排隊時間就是訊號。如果尖峰時段建置要等上幾分鐘以上，就加一台機器。這比每位開發人員乾等的那一小時便宜。

每台 Mac mini 的整台機器都歸您使用：沒有 hypervisor，沒有吵鬧的鄰居。因此有兩種可行的做法。

最單純。一個建置獨占整顆 CPU、GPU 與記憶體。適合 Xcode 建置與 UI 測試，這類建置會吃掉您給它的每一個核心。

適用於工作量小且受 I/O 限制的作業：單元測試、lint、打包。在 32 GB 的 M4 或 M6 上，同時跑兩個輕量作業綽綽有餘。

兩者混用很常見：重型機器專門跑發布建置，輕量機器塞滿快速的作業。

為機器加上標籤，讓 pipeline 把作業分派過去。實用的劃分方式：

ios-app、sdk、internal-tools。每個儲存庫指向自己的標籤，因此一個產品的建置壞掉，絕不會卡住另一個。

pr 機器速度快且隨時待命，release 機器在每次簽署建置前都會清除。

接案公司讓每個客戶擁有自己的機器，以及各自的登入資訊與憑證。沒有共用，帳號之間也就沒有東西會外洩。

全部在同一個 MacDuty 帳號下，月底一張發票。

一台建置了一年的 Mac 會累積多個 Xcode 版本、模擬器與快取。當您把一台機器轉給新專案時，請向支援要求乾淨地重新安裝。由於這會清除 Mac，我們只在您同意後才進行。

同一個 pool 中每台機器使用相同的 Xcode 版本，有計畫地升級。機器版本各自漂移的叢集，會產生在某個 Runner 上通過、在另一個上失敗的建置。

建置機器的 CPU 圖表總是令人緊張，卻很少能據以行動。排隊等待時間才會告訴您何時該加硬體。

有十台機器時，一台故障應該只是不便，而不是事故。

編排平台在虛擬化的 macOS 之上加了一層 Kubernetes 式的排程，而您要為這一層付費。如果您需要大規模地為每個作業啟動臨時 VM，這確實有用。

二十台機器以下的團隊大多不需要。他們需要的是幾台快速的獨享 Mac，保持運作、快取保持熱度，每個月費用固定。獨享叢集就是這樣：固定價格的整台實體機器，建置快取留給下一個作業，而不是隨 VM 一起丟掉。

您還會得到發布前凌晨 2 點才看得出的差別：管理機櫃的人會回覆電子郵件。

告訴我們規模：幾台機器、哪些機型、需要安裝什麼。應您要求，我們會依您的 Xcode 版本、Runner agent、金鑰與憑證進行設定，並在過程中處理重新安裝與機群異動，每一項都經您同意。