Azure Pipelines Apple Silicon：2026 託管還是自託管？

Apple 官方目前將 Xcode 27 標示為 Beta，並確認它只能在 Apple Silicon Mac 上安裝與執行。Xcode 27 Release Notes 因此，症狀是現有 Intel 建置鏈開始遇到版本與相容性風險；最快解法不是把所有正式流水線一次搬到預覽中的託管 Agent，而是保留生產用自託管 Mac，再以託管資源承接短時測試和尖峰併發。

最後更新於 2026 年 8 月 20 日；狀態與支援條件核實自 Microsoft Azure Pipelines 官方文件、Microsoft-hosted Agent 文件、macOS 自託管 Agent 文件 及 Apple Xcode 27 Release Notes。Xcode 27 正式版、Apple Silicon Agent 的 GA 狀態、鏡像、區域、價格與 SLA，在正式上線前仍須重新核實。

先按工作負載決定 Agent 池

這篇文章適合三類決策者：

• 使用 Azure Pipelines 建置和發佈 iOS 應用，正為 Xcode 27 規劃 Apple Silicon 容量的研發效能負責人。
• 管理簽名憑證、內部網路和資料駐留要求，需要審核託管 Agent 風險的企業 IT 或安全負責人。
• 正在比較按分鐘使用、購買 Mac、租用 Mac 與混合部署總成本的技術總監。

Microsoft 已公開 Azure Pipelines 使用 GitHub-hosted Agents 的說明，但這個資源不能與傳統 Microsoft-hosted macOS 鏡像混為一談；曾經暫停的 macOS 15 ARM64 預覽，也不是本次 Apple Silicon 資源的同一產品。企業在建立 Pool 前，應直接核對官方頁面的資源類型、鏡像標籤和目前狀態，而不是依 Azure DevOps 組織所在區域推定建置節點位置。

正式簽名需要可控而非只求免維運

正式發佈流水線與短時驗證的風險完全不同。它需要持久 Keychain、Provisioning Profile、專用發佈帳號、依賴快取和可追溯的產物；任何一項被不當共用，都可能令憑證外洩、撤銷範圍擴大，或使失敗建置難以取證。

自託管 Mac 的價值在於環境可控，但企業也要承擔相應責任：

1. 建立只服務正式簽名的 Agent Pool，不與一般測試任務混用。
2. 為 Pool、專案和流水線分配最小必要權限，避免所有開發者都能觸發發佈工作。
3. 將 Keychain、Profile、App Store Connect 憑證和環境變數分開管理，並設計撤銷流程。
4. 固定 Xcode、SDK、依賴管理工具和腳本版本，變更先在非生產池驗證。
5. 保留建置日誌、簽名操作紀錄和產物雜湊，讓故障或安全事件可以回溯。
6. 定期清理暫存檔、Derived Data 和快取，避免磁碟耗盡造成間歇性失敗。
7. 為 Agent 離線、Mac 重啟、磁碟損壞和憑證失效準備替代節點或人工發佈程序。

Microsoft 的 macOS 自託管 Agent 文件說明了安裝與註冊方式，但文件本身不會替企業完成憑證生命週期、硬體維修或災備設計。macOS 自託管 Agent 文件 這也是為甚麼「自託管」不應被理解成只安裝一次 Agent 就結束。

對需要遠端操作的團隊，我們會把管理通道和建置通道分開，並先建立一台隔離的 Apple Silicon Mac 做驗收。若企業需要比較不同地區的 遠端 Mac 主機方案，應把連線方式、root 權限、資料清理和交付流程一併列入審查，而不是只看主機名稱。

發佈高峰適合採用雙池路由

對多數企業而言，固定容量與彈性容量並不是二選一。較穩健的架構是以受控自託管 Mac 作為生產基線，再以 Apple Silicon 託管 Agent 承接短期峰值、非簽名測試和可延後任務。

實作可按以下步驟進行：

1. 盤點工作負載：從 Azure Pipelines 建置紀錄分出 PR、日常 CI、Beta 測試、正式簽名和重跑任務。
2. 定義安全標籤：例如將 signing、private-network、long-running 指向自託管池，將 untrusted、validation 指向託管池。
3. 建立兩個 Agent Pool：生產池只接受必要專案；彈性池不得讀取正式憑證或內部秘密。
4. 在 YAML 模板分流：以條件、需求標籤或模板參數指定池，不要讓相同 Job 在兩池間隨機漂移。
5. 固定建置輸入：鎖定 Xcode、SDK、依賴檔、Ruby 或 Node 工具版本，並記錄每次鏡像與 Agent 版本。
6. 先跑無簽名基準：比較成功率、佇列等待、建置時間、快取命中和失敗重跑，不要一開始就搬移發佈憑證。
7. 再驗證簽名隔離：用非生產憑證測試撤銷、重跑、權限拒絕和節點離線情境。
8. 設定擴容觸發點：只有當真實佇列和建置紀錄顯示等待時間、並發或發佈窗口受到影響，才增加託管容量。
9. 每次版本狀態變化後複核：Xcode 27 正式版、Apple Silicon Agent GA、鏡像標籤或價格變更，都應重新跑兼容性和安全測試。

Azure DevOps 的自託管 Mac 適合固定環境與受控網路，但不代表每個任務都應放在同一台主機。Agent Pool 權限、簽名秘密和任務標籤若沒有分層，雙池架構只會把混亂從一個節點擴大到兩個節點。

試點紀錄要能直接支援採購決策

企業不要用單次成功建置就宣佈遷移完成。試點至少需要留下以下證據：

• 兼容性：現有專案是否能在 Apple Silicon 與 Xcode 27 Beta 環境完成編譯、測試和產物封裝。
• 可靠性：成功率、失敗類型、重跑比例和節點離線後的恢復結果。
• 容量：佇列等待、同時執行需求、發佈窗口是否出現阻塞。
• 安全性：簽名憑證是否只在指定 Pool 出現，非可信任務是否能被拒絕。
• 網路：私有制品庫、內部 API、出口白名單和資料駐留要求是否逐項通過。
• 運維：Xcode 或鏡像更新、快取清理、遠端重啟和故障復原所需的人力。
• 財務：有效建置分鐘、閒置容量、託管用量、租用或購買主機成本，以及每次失敗重跑的影響。

可採用以下准入邏輯：

• 測試兼容性通過、沒有秘密暴露，且尖峰佇列明顯：繼續使用託管彈性池。
• 正式簽名、私有網路或資料駐留無法由託管方案證明：採購或租用隔離的自託管 Mac。
• 日常 CI 穩定、發佈高峰明顯：維持自託管基線，按需加入託管容量。
• Xcode 27 仍未完成正式版核實，或兩種環境的失敗原因尚未釐清：暫緩正式遷移，只擴大非生產試點。

若需要進一步評估主機取得方式，可先閱讀 Mac 主機購買與租用選項，再將租用主機作為自託管 Agent 的隔離試點；重點不是先承諾租用一定更便宜，而是取得真實的建置、佇列和遠端復原資料。

對企業現有的「全部使用單一 Microsoft-hosted Agent」方案而言，常見缺點是環境控制有限、正式簽名難以與一般任務隔離，以及私有網路與資料駐留條件未必能被充分證明；若改成全部自建實體 Mac，又會承擔採購、折舊、維修、閒置容量和故障復原責任。以 VNCMac 提供的遠端真實 Mac 建立一台隔離自託管節點，可以先驗證 Apple Silicon、Xcode 27 和簽名流程，再依紀錄決定固定容量與託管彈性容量的比例；這對仍在評估期、需要臨時算力或不想立即承擔整批硬體採購的團隊，通常比一次性全面遷移更容易控制風險。