macOS 26.6 CI 升級不應採用全池同步自動安裝。先依照 Xcode 27 官方系統要求 找出必須升級的節點，再執行試點、任務排空、分批重啟與真實流水線驗收；生產簽名節點則保留未升級節點或短期備用的遠端 Mac。
這篇內容適合三類人：管理長期在線 Mac CI 節點、需要安排 macOS 26.6 維護窗口的企業 IT 負責人；準備導入 Xcode 27、但不能接受全池停機的研發效能負責人；以及需要核查 FileVault、更新授權、遠端恢復與備用容量的安全或基礎設施負責人。
最後更新於 2026 年 9 月 18 日。 版本要求與更新機制核實自 Apple Developer 的 Xcode 系統要求及 Apple Platform Deployment 文件；不同管理平台的實際支援能力，仍須以你的平台文件與企業記錄為準。
01 先把 macOS 26.6 更新分成三種維護動作
不要把「背景安全更新」、「同代 macOS 26.x 更新」和「跨大版本升級」視為同一件事。它們可能有不同的重啟、授權和相容性影響。Apple 的部署文件也將軟體更新管理、強制安裝與重新啟動行為分開說明，不能只看管理主控台顯示的「已完成」。
| 維護類型 | 主要判斷 | 對 Mac CI 的處理 |
|---|---|---|
| 背景安全更新 | 修補安全元件，但仍要確認是否需要重啟 | 先在非關鍵節點驗證，再安排低峰期套用 |
| macOS 26.6 同代更新 | 可能改變系統元件、開發工具或重啟狀態 | 以 Xcode 27 與現有工具鏈分池驗證 |
| 跨大版本升級 | 兼容範圍、驅動與管理行為變化較大 | 不納入一般補丁批次，另建遷移計畫 |
Apple 的軟體更新部署說明可用來核對更新政策、安裝方式與管理限制。它不能替你證明某個 CI Runner、簽名流程或第三方相依套件一定可用。
macOS 自動更新是否會重啟正在構建的 CI 節點？
只要更新流程觸發重新啟動，就可能中斷仍在執行的 Job。不要把「自動更新已啟用」理解成「CI 會安全排空」。排空與隊列路由必須先由 Runner 或 CI 平台完成，否則更新程序可能與編譯、測試或封裝程序同時運作。
02 日常 PR 構建池：先排空，再以小批次放量
日常 PR 節點的容錯通常高於正式發布節點，但「容錯較高」不代表可以直接全池更新。你要保留尚未維護的節點，讓新任務有地方執行，也讓升級失敗時可以回退隊列。
升級 macOS 26.6 前要不要先停止 Runner 接單？
要。先將目標節點標記為不可接收新任務，再等待現有 Job 正常完成。確認沒有執行中的構建、測試、快取寫入或產物上傳後，才開始更新。若無法取得可信的任務狀態，就不要直接重啟；先把節點從路由中移除，並保留人工核查。
| 升級階段 | 你要核對的狀態 | 未通過時的處理 |
|---|---|---|
| 排空前 | Runner 狀態、執行中 Job、隊列路由 | 暫停升級，先處理殘留任務 |
| 重啟前 | macOS 版本、Xcode 路徑、依賴鎖定檔、節點標籤 | 保存記錄，避免升級後無法比對 |
| 重啟後 | 主機在線、Runner 在線、Xcode 可呼叫 | 只在線但工具不可用時，不恢復接單 |
| 首條驗收 | 乾淨構建、測試、產物保存 | 將節點留在隔離池，查明差異 |
| 放量前 | 真實 PR 流程與錯誤記錄 | 回退至未升級節點 |
最小操作流程如下：
- 將目標節點切換為
drain或等效排空狀態。 - 等待現有 Job 完成，記錄最後一個 Job 的識別碼與結果。
- 保存升級前的 macOS、Xcode、Runner 及依賴版本。
- 執行更新並重啟，不要在仍有構建程序時強制關機。
- 核查主機連線、Runner 服務、Xcode 路徑與簽出權限。
- 先跑一條乾淨構建，再跑一條接近日常 PR 的真實流水線。
- 通過後才移除排空標籤，並將下一批節點導入維護。
CALMVPS 的遠端 Mac 服務可作為短期維護窗口的候選資源，但你仍須先用相同專案完成驗收，不能因為主機可連線就直接接管生產隊列。
03 生產簽名節點：維護窗口要獨立於 PR 池
正式歸檔、代碼簽名與上傳任務不應沿用日常 PR 節點的更新節奏。這些任務的失敗不只是重跑一次構建，還可能涉及憑證私鑰、Keychain、App Store Connect 憑證、發布審計與版本追蹤。
| 驗收領域 | 必須確認的證據 | 不能替代的狀態 |
|---|---|---|
| 歸檔 | 以生產設定完成 Archive，產物可保存 | 主機在線 |
| 簽名 | 指定憑證與私鑰可用，簽名結果可檢查 | Runner 在線 |
| 上傳 | 使用正式憑證完成上傳或受控驗證 | Xcode 可開啟 |
| 審計 | 保留 Job、操作者、產物與錯誤記錄 | 構建成功 |
| 回退 | 未升級節點或乾淨備援仍可接單 | 單一節點恢復 |
維護前先凍結發布任務，確認正在進行的 Archive 不會被更新打斷。把簽名節點與普通 PR 池分開標記，並寫清楚回滾邊界：哪些任務可以轉移、哪些任務必須等待原節點恢復、哪些憑證不可複製到臨時主機。
你可以把 CALMVPS 的方案與週期資訊納入備援採購評估，但不要只用租賃週期判斷是否適合發布。真正的准入條件是：相同專案能否完成歸檔、簽名、上傳與審計記錄。
04 Apple Silicon 無人值守節點：先證明能恢復，再安排更新
Apple Silicon 構建機的無人值守更新，關鍵不只是「是否有管理權限」。Apple 的文件將 bootstrap token、secure token、volume ownership 和軟體更新授權分別描述；通用能力不等於你的 MDM 或管理平台已正確實作所有流程。
參考 Apple 的更新授權說明與 bootstrap token 文件，逐項核對以下狀態：
- FileVault 開機解鎖是否不需要現場輸入。
- 更新後磁碟區是否能正常解鎖。
- 使用者工作階段或系統服務是否按預期啟動。
- CI Agent 是否自動啟動並向控制端回報。
- SSH、VNC 或其他遠端管理通道是否恢復。
- 節點恢復後是否能完成一條真實構建。
Apple Silicon 構建機的無人值守升級需要什麼授權？
你至少要確認管理平台可取得並正確使用更新所需的裝置授權、啟動磁碟擁有權與安全令牌狀態。不要只看 MDM 顯示「命令已送出」。應先安排一次受控重啟演練：把節點放入非生產池，遠端發起重啟，觀察它是否能自行解鎖、啟動 Agent、接收任務並完成真實構建。
Apple 對受管裝置軟體更新的執行與強制重啟有官方說明；至於你的平台能否回傳完整狀態，必須另外查閱該平台文件。主機重新上線，不代表 Runner、Xcode、簽名和上傳流程全部恢復。
05 跨地域節點：以業務時區錯開維護批次
多地域機群不應只按照機房清單排程。你需要同時看隊列路由、發布窗口與當地值班能力。建議先把拓撲分成三類：
| 節點類型 | 維護策略 | 主要回退資源 |
|---|---|---|
| 單一機房的 PR 池 | 先維護部分節點，讓其他節點承接隊列 | 尚未升級的同池節點 |
| 跨地域構建池 | 按業務時區錯峰，避免多地同時失去容量 | 其他地域的相容節點 |
| 共享簽名節點 | 獨立維護窗口，發布時段禁止隨意更新 | 已驗收的未升級節點或臨時遠端 Mac |
Mac CI 滾動升級需要保留多少備用容量？
不要套用固定百分比。實際需求取決於同時執行的 Job、最長構建時間、隊列可接受等待時間、簽名任務是否能轉移，以及未升級節點的工具鏈是否相容。先用企業記錄計算「維護期間仍需完成的最大並行任務」，再確認剩餘節點能否承接；若不能，就延後批次或增加臨時節點。
把節點標籤與隊列路由寫成可驗證規則。例如，升級中的節點只能進入維護池；已驗收節點才可進入 PR 池；簽名任務只能路由到完成簽名驗收的節點。短期遠端 Mac 應先作為維護峰值或故障回退資源，不要未經測試就接管正式發布。
06 緊急補丁：用條件決定加速或暫緩
遇到高風險安全修補時，不應簡化成「立即全部更新」或「一律延後」。至少要同時判斷安全風險、對生產的影響、工具鏈相容性和可回退性。
| 判斷結果 | 執行決策 | 必要證據 |
|---|---|---|
| 安全風險高，試點已通過 | 加速滾動放量 | 試點構建、重啟與回報正常 |
| 安全風險高，但簽名未驗收 | 先維護非簽名池 | 未升級簽名節點仍可發布 |
| 相容性結果不明，無回退容量 | 暫緩生產升級 | 已記錄風險與補測計畫 |
| 節點恢復異常 | 切換乾淨備用節點 | 備用節點完成相同流水線驗收 |
你的決策條件可以直接寫成以下分支：
- 若 Xcode 27 的系統要求與節點版本不符，則先建立隔離升級池，不讓該節點承擔生產任務。
- 若節點能排空、能遠端恢復，且乾淨構建通過，則加入下一個小批次。
- 若主機在線但 Runner 或 Xcode 不可用，則維持隔離，不把「在線」當成通過。
- 若簽名、上傳或審計驗收失敗，則回到未升級節點或已驗收的遠端 Mac。
- 若沒有足夠冗餘容量，則不要開始全池維護；先建立短期備用節點並跑完整驗收。
07 你可以直接採用的維護檢查清單
- [ ] 已核對 Xcode 27 官方系統要求。
- [ ] 已把背景安全更新、同代更新和跨版本升級分開。
- [ ] 已為 PR、簽名發布和備用節點建立不同標籤。
- [ ] 已確認 Runner 能排空，而不是只在主控台停用。
- [ ] 已保存升級前 macOS、Xcode、依賴與節點狀態。
- [ ] 已完成 FileVault、更新授權和遠端重啟演練。
- [ ] 已驗證主機、Runner、Xcode、構建、簽名和上傳六個層級。
- [ ] 已確認維護期間的隊列等待上限與回退路由。
- [ ] 已把錯誤、Job 識別碼、產物和審計記錄歸檔。
- [ ] 已讓未升級節點或臨時遠端 Mac 通過相同專案驗收。
如果你目前的方案是讓所有 Mac CI 節點接受同一條自動更新政策，缺點通常很明確：它可能同時重啟多台主機、沒有按工作負載區分維護窗口，也無法證明簽名和上傳流程已恢復。若節點池沒有冗餘，正式升級前可先透過 CALMVPS 的遠端 Mac 申請頁面配置一台短期主機，跑通同一專案的真實流水線，再把它作為維護期間的臨時構建或回退節點。對需要臨時容量、測試環境或恢復演練的團隊，這比在唯一生產節點上直接下注更容易控制風險；但長期固定重負載、需要實體介面或必須完全自行掌控硬體的團隊，仍應評估自購與託管方案。