團隊專屬建置流程

把排隊中的流水線
搬到專屬 Mac

Apple Silicon M4 Mac mini，整台機器專供單一客戶使用。讓 PR 檢查、夜間封存與遠端 Xcode 共用一套受控工具鏈，不必和其他租戶爭用 CPU。

租用 macOS 建置節點查看三步遷移流程

兩種 M4 規格 · 每天 $20 起 · 專屬實體機，非虛擬機

你的團隊流程

PR提交檢查
Test編譯與單元測試
Archive封存與發佈

專屬的是整台機器。團隊內工作的並行數與優先順序，取決於你的 runner 設定。

先分配工作，再配置資源

將四類工作安排進建置流程

先決定機器的主要用途，再選擇記憶體與儲存空間。互動式開發、發布封存與模型實驗可使用同類型節點，但不適合不設限制地共用同一台機器。

情境一 · PR 檢查

每次提交都執行編譯與單元測試

適合單一專案 CI、SwiftUI 小型 App，以及想先將辦公室建置機遷移至雲端的團隊。每次 PR 都觸發程式碼檢出、還原相依套件、執行單元測試，並將結果回傳至原有 CI 平台。

建議從 Merge M4 S 入門：Apple Silicon M4、16GB RAM / 256GB SSD。整台機器供單一客戶使用，編譯工作不會和其他租戶爭用核心；團隊內部的工作仍應設定並行上限，避免多個建置同時耗盡記憶體。

第一條流水線先做三件事

固定儲存庫提交版本、相依套件鎖定檔與 Xcode 版本。
先用一個 scheme 執行編譯與單元測試。
記錄等待、編譯、測試三個階段，分別找出耗時所在。

規格選擇：若多個 target 或平行模擬器測試明顯增加記憶體用量，再評估 24GB 規格；不要單憑團隊人數推算所需機器數量。

租用 Merge M4 S

情境二 · 每日發布

將 nightly 封存交給發布節點

適合每日產生測試版、定時封存，以及使用 Fastlane 自動打包的團隊。沿用現有 lane，將封存、匯出與上傳至 TestFlight 串成單一發布工作。

建議選擇 Merge M4 L：Apple Silicon M4、24GB RAM / 512GB SSD。相較入門規格，記憶體與本機儲存空間更充足，方便保留多個專案的相依套件與必要的模擬器執行環境；實際建置效能仍取決於專案與快取狀態。

為發布工作設一道專屬關卡

使用獨立 runner 標籤，避免一般 PR 工作佔用封存時段。
透過 CI 密鑰注入憑證、描述檔及發佈所需的認證資料。
封存成功後保存日誌與產出檔，再依規則清理本機檔案。

規格選擇：節點全年 365 天正常運作；定時工作是否觸發、上傳是否成功，仍須在 CI 平台設定失敗通知與重試。

租用 Merge M4 L

情境三 · 遠端開發

沒有本機 Mac，也能使用 Xcode

透過 VNC 螢幕共享使用 macOS 圖形介面，在 Xcode 中檢視專案、排查編譯錯誤及執行模擬器；透過 SSH 執行命令列建置、同步檔案與管理 runner。

若需同時開啟 Xcode、模擬器與相依工具，建議優先評估 Merge M4 L。圖形介面與 CI 工作會共用同一台實體機的資源，建議錯開互動式除錯與自動封存的時間，或分配至不同節點。

先確認連線，再搬移完整專案

從控制台取得執行個體連線資訊，先確認 SSH 與 VNC 均可連線。
降低遠端畫面解析度，確認輸入與視窗操作反應正常。
先用小型專案測試 Xcode 與模擬器，再同步正式專案。

使用範圍：雲端適合編譯、簽署與模擬器測試，但無法直接連接你手邊的 iPhone。需要連接本機實機的工作流程應另外保留。

查看 SSH 與 VNC 連線說明

情境四 · AI 實驗

為 MLX 實驗預留資源

在 Apple Silicon 上執行 MLX 本機推論，測試量化模型與小型模型微調流程。先以較小的模型建立可執行基準，再逐步增加上下文長度、批次大小與訓練資料量。

建議選擇 Merge M4 L，並加購 +2TB SSD，將模型權重、資料集與檢查點存放在擴充儲存空間。24GB RAM 是執行時記憶體預算，額外 SSD 則是檔案儲存空間，兩者無法互相取代。

關注記憶體峰值，不只看模型檔案大小

記錄模型載入、推論與微調各階段的記憶體峰值。
為下載、解壓縮與檢查點預留額外磁碟空間。
暫停同機 CI 工作並行，避免資源競用影響實驗結果。

規格限制：模型能否載入記憶體，還取決於量化精度、上下文長度與執行方式。+2TB SSD 加購項目不會增加記憶體，也不保證所有模型都能執行。

設定 Merge M4 L 與擴充儲存空間

專屬一台機器，不代表工作可以無限並行。先限制單機並行數，再觀察記憶體峰值、剩餘磁碟空間與工作等待時間。若發布工作需要穩定時段，優先拆分 runner 的職責，而不是把所有工作都塞進同一條佇列。

依相依順序逐步遷移

先重現環境，再切換流水線

一開始不要停用原有建置機。依序完成資料、工具鏈與 CI 整合，再以相同提交在新舊環境各執行一次；確認產出檔與日誌無誤後，再切換正式工作。

01 · 資料

分開搬移專案、簽署資料與快取

從儲存庫重新檢出專案與子模組，保留相依套件鎖定檔；不要直接複製整個本機工作目錄，並將它當成可重現的環境。
- 透過受控管道傳輸憑證與描述檔，並將密碼存入 CI 密鑰。
- 依 Xcode 版本、相依套件鎖定檔與架構設定快取索引鍵。
- 只遷移確認可重複使用的快取；舊的 DerivedData 不應是必要輸入。
驗收標準：指定提交可成功檢出、可找到簽署檔案，且敏感資料未提交至儲存庫。
02 · 工具鏈

記錄版本，不要只靠記憶

確認 Xcode、Homebrew、Ruby 與 CocoaPods 版本一致。優先參照專案現有的版本檔案，避免遷移時順手升級相依套件，讓問題來源變得難以判斷。
```
xcodebuild -version
xcode-select -p
uname -m
ruby --version
bundle exec pod --version
```
驗收標準：確認環境為 arm64、Xcode 路徑與相依套件版本符合預期，再使用一個 scheme 完成命令列建置。
03 · CI 整合

先接入測試工作，再接正式發布

依照現有平台註冊 self-hosted runner 或 agent，並為節點設定清楚的標籤。GitHub Actions 可使用以下工作標籤；其他平台則沿用各自的排程設定。
```
runs-on:
  - self-hosted
  - macOS
  - ARM64
  - macos-m4
```
驗收標準：確認已註冊相同標籤、測試分支能派送至新節點，且日誌與產出檔可取回；正式切換前保留原 runner 的回復設定。

不要將註冊權杖或簽署資料寫入範例指令或公開日誌。節點變更後，檢查 CI 平台上的 runner 上線狀態、工作標籤與觸發條件；三項均正確後再開放團隊使用。

查看 runner 整合與疑難排解

讓遷移結果可供查核

在團隊例會中比較相同提交

建置時間只比較相同輸入。分開記錄快取命中與未命中的結果，避免將單次下載、重試或測試範圍變更誤判為硬體差異。

筆電開發工作情境，團隊在例會中檢視建置日誌與遷移紀錄 — 開發協作情境示意圖。建置比較應以團隊自己的 CI 日誌為準，圖片不代表客戶案例或效能證明。

固定輸入條件

記錄提交雜湊、Xcode 版本、scheme、測試裝置與相依套件鎖定檔。比較前確認測試範圍沒有變更。

拆分各階段耗時

分別檢視等待、下載相依套件、編譯、測試、封存與傳送產出檔的時間。整台機器專屬使用可避免與其他租戶競用資源，但無法消除網路傳輸時間。

保留回復方案

保存原有 runner 標籤與流水線設定。確認新環境可重複執行後，再停止舊節點承接正式工作。

依使用情境選擇規格

PR 檢查可從 16GB 開始；多個 target、模擬器與發布封存則建議評估 24GB。前往方案頁面核對規格表、四種計費週期與儲存空間加購項目，再為團隊建立專屬建置流程。

查看規格比較表立即租用雲端 Mac

把排隊中的流水線搬到專屬 Mac