2026年Buildkite自託管macOS Agent對接按天雲Mac：突發建置彈性、Artifact留存與佇列SLO決策矩陣FAQ

Buildkite 把編排在 SaaS、執行落在自託管 Agent，很適合「控制面要輕、執行面一定要 Apple 硬體」的 iOS 團隊。把 macOS Agent 接到按天計費的雲 Mac 時，真正要拍板的是三件事：機器契約是否涵蓋冷啟動與映像預熱、突發下佇列是否仍滿足 SLO、Artifact 與日誌留存是否經得起稽核與復盤。若你也在評估託管 CI 與按天雲 Mac 自託管 Runner 的邊界，可先對照 2026年App Center停用遷移窗口：短週期行動建置用託管 CI 還是按天雲 Mac 自託管 Runner？私有相依與簽署注入決策矩陣 FAQ 裡的決策權重，再回到 Buildkite 的佇列與步驟模型細調。

按天雲 Mac 與 Agent 的契約：標籤、佇列與冷啟動

按天雲 Mac 通常隱含「工作階段結束即回收」的風險邊界，Agent 不應假設磁碟狀態跨日一致。實務上為 Buildkite 佇列設定兩組 tag：一組指向長期穩定的「基準映像」節點，另一組指向可快速擴容的 burst 節點；Pipeline 以 agents.queue 與 agents.os 等條件把重 Xcode 步驟導到 burst，把輕量腳本留在常駐池，可避免尖峰把單機磁碟 IO 打滿。首次註冊 Agent 時，把網路自檢、權杖最小權限與回連寫進同一張核對清單，能顯著降低「Agent 在線卻拉不到倉庫」的假陽性。

若你在主幹與發佈分支之間要區分優先度，可在組織層約定「阻塞型步驟」只允許落在具備固定主機名與金鑰輪替紀錄的佇列；burst 節點僅承接可重試、可取消的編譯與測試。這樣即使雲端供應商短暫回收機器，也不會讓簽章或內網憑證注入流程與「可突發擴容」綁在同一風險面上。

突發建置彈性：何時加 Agent、何時降並行

Buildkite 的佇列曲線往往比平均建置時長更敏感：一次發佈視窗就能把 p95 等待拉到不可用。我們傾向先看「佇列深度 × 單步時長」而不是只看 CPU。若 p95 等待持續高於團隊可接受閾值，優先增加帶相同 tag 的 burst 雲 Mac Agent，而不是盲目提高單一 Pipeline 的並行度——後者容易觸發 Xcode 與連結器的記憶體尖峰，反而拉長尾延遲。快取與 DerivedData 要放在節點本機碟還是遠端掛載，會直接影響 burst 恢復速度，可搭配 2026 短週期雲 Mac CI：遠端建置快取（DerivedData／Pods／sccache）對比節點本機碟——冷啟動、同步頻寬與複用決策矩陣（可執行參數清單） 的比較結論，決定 burst 節點是否只做「無狀態執行」。

Artifact 留存：Buildkite 託管、物件儲存與合規視窗

短週期建置裡，Artifact 既要給下游測試取包，又要滿足「數週後可復現」的稽核需求。預設託管 Artifact 適合小體積日誌與報告；ipa、dSYM 或大型 xcresult 更建議落到團隊自有儲存桶並設定生命週期：熱資料保留滿足排障，冷資料依合規週期下沉或刪除。關鍵是讓 Pipeline 的保留策略與儲存桶 TTL 同源設定，避免出現「Build 紀錄還在、物件已過期」的斷層。

佇列 SLO 決策矩陣（簡版）

把「可接受的等待上限」寫進 SLO，比單純追求建置分鐘數更貼近業務體感。下表用於評審會議白板對齊。

# 重步驟走 burst 佇列；輕步驟走預設佇列
steps:
  - label: ":iphone: Archive (burst)"
    agents:
      queue: "mac-burst"
      os: "darwin"
    commands:
      - xcodebuild -scheme App archive ...
  - label: ":mag: Lint (baseline)"
    commands:
      - swiftlint

FAQ 速查

• 按天機器能否跑常駐 Agent？ 可以，但要把「磁碟可能被重置」寫進快取與 Artifact 策略，避免隱性依賴上次建置殘留。
• Buildkite 與內網 Git 如何配合？ 優先走唯讀 deploy key 或短期權杖，並在 Agent 啟動指令稿裡做連通性探測，失敗即退出以免佔位佇列。
• SLO 應監控什麼？ 等待 p95、步驟重試率、Artifact 上傳失敗率，以及「從觸發到可下載產物」的端到端時間。