Azure Pipelines macOS-14 下線：2026 企業遷移怎麼選

Azure Pipelines macOS-14 下線：2026 企業遷移怎麼選

截至 2026 年 9 月 20 日，Azure Pipelines 的 macOS-14 託管鏡像已進入停用流程，官方計劃於 2026 年 10 月安排 brownout，並在 2026 年 11 月 2 日移除；時間表應以官方託管 Agent 文件及發布前複核結果為準。這代表獲勝方案不是把所有工作直接改成 macOS-latest，而是將無狀態 PR 建置遷移至已驗收的託管鏡像，將固定工具鏈、私網依賴及生產簽名工作放入自託管 Mac，先雙軌運行，再關閉 macOS-14。

這篇文章適合仍使用 macOS-14、需要在移除前完成流水線遷移的 Azure Pipelines 管理者。企業 IT、研發效能、安全團隊，以及負責 Xcode、私有依賴、程式簽名和發布連續性的技術負責人，都可用這套分流方法作為遷移決策底稿。

先建立 macOS-14 遷移資產表

流水線現在「成功」，不等於遷移可以延後。brownout 的作用正是提前製造失敗窗口，讓固定使用舊鏡像的任務暴露出來。企業應先區分兩類風險：

  • 鏡像移除風險：YAML 仍固定寫入 macos-14，或依賴該鏡像預裝的 Xcode、SDK、Simulator Runtime。
  • 普通建置故障：依賴解析失敗、憑證過期、私網連線中斷、快取損壞或腳本本身不相容。

第一類不會靠重試解決。第二類則需要另外建立故障紀錄，不能把所有紅燈都歸因於鏡像下線。

建議先匯出以下欄位：

欄位 要記錄的內容
工作名稱 PR、夜間測試、歸檔、發布或回歸任務
鏡像與 Agent vmImage、Agent Pool、Microsoft-hosted 或自託管
工具鏈 Xcode 版本、SDK、Simulator Runtime、Ruby、CocoaPods 或 Swift Package
網路依賴 內部 Git、制品庫、固定出口、私有 API
憑證資產 signing certificate、provisioning profile、Keychain 及存取帳號
負責人 開發、研發效能、安全或 IT
阻斷項 尚未支援的插件、舊 SDK、固定腳本或發布審批

YAML 盤點可先從搜尋固定鏡像與工具鏈開始：

grep -RInE 'macos-14|macOS-14|Xcode|xcodebuild|simctl|installApple' \
  azure-pipelines*.yml .azure-pipelines/

預期輸出應能列出所有鏡像標籤、Xcode 選擇、模擬器建立及簽名任務。若某個模板由其他儲存庫引用，也要把模板來源納入資產表；只掃描主 YAML，容易漏掉真正的 pool 設定。

無狀態 PR 與新版託管鏡像

無狀態 PR 建置通常最適合先遷移。這類任務不應依賴節點上一次留下的檔案，也不應把生產憑證放在 Agent 上。編譯、單元測試、Lint 和基本靜態檢查若能在乾淨環境完成，可先比較受支援的 macOS-15、macOS-26 或其他正式可用標籤。

但 macOS-latest 不是固定版本承諾。它可能在鏡像更新後帶來 Xcode、SDK、Ruby 或系統工具變化。遷移判斷應依據官方鏡像清單及 Azure Pipelines 當時的官方可用標籤，而不是只看 Agent 能否成功啟動。

驗證至少要做兩次：

  1. 使用目前 macOS-14 跑基準提交。
  2. 使用候選鏡像跑完全相同的提交。
  3. 比較依賴解析、編譯警告、單元測試及產物內容。
  4. 清除快取後重跑，確認結果不是由舊快取掩蓋。
  5. 將候選鏡像設為 PR 隔離池，觀察一個完整變更週期。

託管 Agent 的乾淨環境是優點，也是限制。每次 Job 重建後，手動安裝的工具和本地檔案都會消失。快取鍵必須包含作業系統、Xcode 和依賴鎖定檔，否則會出現「本地成功、乾淨節點失敗」的假象。

pool:
  vmImage: 'macos-15'

steps:
- script: |
    xcodebuild -version
    xcrun simctl list runtimes
  displayName: '記錄 Xcode 與 Simulator Runtime'

- script: |
    bundle exec pod install --deployment
    xcodebuild \
      -workspace App.xcworkspace \
      -scheme App \
      -sdk iphonesimulator \
      -destination 'platform=iOS Simulator,name=iPhone 16' \
      test
  displayName: '執行可重現測試'

輸出示例：

Xcode 16.x
iOS Simulator Runtime: available
Test Suite 'All tests' passed

上面的版本輸出只應作為驗收紀錄，不代表所有團隊都應使用同一版本。正式版本、可用標籤和預裝軟體，必須以實際執行日的官方清單為準。

舊 SDK、Xcode 27 與固定工具鏈

需要歷史 SDK、指定 Simulator Runtime、舊插件或固定 Xcode 小版本的任務，不宜直接切換到 macOS-latest。這些任務的問題不是「能否安裝 Xcode」，而是能否保持可重複建置。

Xcode 27 可作為相容性驗證方向，但其鏡像狀態須以官方 Xcode 27 Arm64 鏡像說明為準。即使鏡像已可用，也不能僅因版本較新便替換生產池。對企業來說，Xcode 27 的驗收範圍至少包括：

  • Swift Package、CocoaPods 或其他依賴解析。
  • 真實專案的編譯與警告基線。
  • 實際使用的 Simulator Runtime。
  • Archive、exportOptions 及產物內容。
  • 開發簽名與生產簽名的完整流程。
  • 失敗後能否退回上一個已驗收節點。

注意： Apple Silicon、Xcode 27 和新 macOS 鏡像的可用性會隨官方清單變化。預覽鏡像適合相容性驗證，不應在沒有真實專案驗收時直接承接生產發布。

Apple Silicon 的判斷也要分層。Microsoft-hosted 鏡像、按量託管 Apple Silicon Agent、自託管 Apple Silicon Mac，並不是同一種運行方式。原生架構需求、可控制的工具安裝範圍、節點重建方式和故障回退能力都不同。凡是依賴原生工具、特定二進位檔或架構敏感插件的任務，都應在真實專案中確認，而不是只檢查 uname -m。

私網依賴與生產簽名節點

一旦流水線需要連線內部 Git、私有制品庫或固定出口，託管鏡像的便利性就不再是唯一判斷標準。企業還要回答三個問題：

  1. Agent 能否在不繞過安全邊界的情況下存取私網？
  2. 建置失敗時，是否可能把原始碼、憑證或產物暴露給其他工作？
  3. 節點重建後，工具鏈和 Keychain 是否仍能由受控流程恢復？

生產簽名應與普通建置池分離。PR 任務不應與發布任務共用存有生產憑證的 Agent Pool。自託管 macOS Agent 的運行帳號、檔案權限、遠端登入和清理方式，也要納入官方 macOS Agent 安全說明的檢查範圍。

建議的隔離層次如下：

  • 一般建置池：只處理編譯、單元測試和靜態檢查。
  • 固定工具鏈池：限制 Xcode、SDK 和 Simulator Runtime，禁止不必要的專案共用。
  • 生產簽名池：只接受受審批的發布 Pipeline，使用權限更窄的運行帳號。
  • 備用節點：定期執行恢復演練，不把「曾經成功啟動」當成災備證據。

Agent Pool 權限、Pipeline 使用權限和服務連線權限需要分開審核。官方流水線安全建議明確把權限和機密保護列為流水線安全的一部分。企業可畫出憑證流向圖：誰能觸發工作、誰能讀取 Keychain、誰能上傳簽名產物、誰能批准生產發布。任何一條不必要的路徑，都應在遷移前移除。

雙軌遷移與回退驗收

遷移不是一次改 YAML。較穩妥的流程如下：

第一步：建立任務資產表。
把所有 vmImage、Xcode、Simulator Runtime、私網端點、簽名任務和負責人列出，並標記阻斷項。

第二步：按場景分流。
無狀態 PR 任務先進候選託管鏡像；固定工具鏈、私網依賴及生產簽名任務先保留在自託管 Mac。

第三步：以同一提交雙跑。
不要用不同分支或不同依賴鎖定檔比較。至少保存依賴解析、編譯、測試和 Archive 的結果。

第四步：驗證發布鏈路。
確認 provisioning profile、Keychain、簽名身份、exportOptions、制品上傳及發布審批均可完成。僅有「編譯成功」不足以關閉舊池。

第五步：檢查恢復能力。
讓節點重啟、清理工作目錄，再執行一次完整任務。若自託管 Mac 無法在故障後恢復，便需要備用節點或改用按周期交付的專用節點。

第六步：保留回退路徑。
在 brownout 到正式移除之間，保留已驗收的舊任務紀錄、產物和變更審批。正式切換後，回退應指向另一個已驗收池，而不是依賴已被移除的 macOS-14。

需要自託管節點部署、重啟和驗收的團隊，可參考 Azure Pipelines 自託管 macOS Agent 的部署思路；這裡的重點不是安裝命令，而是把節點納入可審核、可恢復的運行流程。

提醒： 只有在依賴解析、編譯、測試、歸檔和簽名發布全部通過後，才可把任務從「遷移中」改為「已切換」。Agent 上線、第一個 Job 綠燈或快取命中，都不能代替完整驗收。

企業決策矩陣

下表用工作負載作為分流單位。成本不能脫離排隊、維護、恢復和簽名隔離單獨計算；實際租賃費用也應依Mac 遠端租賃方案與週期核對，而不是套用未經確認的市場數字。

工作負載 優先選項 遷移條件 主要風險 回退方式
無狀態 PR 編譯、單元測試、Lint 受支援的託管鏡像 雙跑結果一致，無私網及生產憑證依賴 預裝工具及 SDK 變化 切回另一個已驗收託管標籤
固定 Xcode 小版本或舊 Simulator Runtime 自託管 Mac 工具鏈能由受控腳本恢復 節點維護與重啟恢復 保留短期兼容池或備用 Mac
私有 Git、制品庫、固定出口 自託管 Mac 網路、帳號及 Agent Pool 完成最小權限驗證 憑證與原始碼暴露 切換至隔離備用池
生產簽名及發布 專用自託管 Mac 完成 Archive、簽名、上傳及審批驗收 生產憑證集中在敏感節點 使用另一個已驗收簽名節點
PR 高峰與發布高峰並存 混合節點池 一般建置與簽名任務分池 排隊或容量不足 保留按周期交付的備用節點

混合方案不是把所有節點混在一起，而是讓不同場景使用不同信任邊界。日常 PR 可交給託管鏡像，固定工具鏈與生產發布則由自託管 Mac 承擔。關閉 macOS-14 前，至少要有排隊時間、任務成功率、工具鏈一致性、恢復結果和完整 TCO 的企業內部記錄；若沒有這些證據，應延長雙軌階段，而不是批量切換。

對於需要先做小規模 PoC 的團隊，可把一條真實 PR 流水線和一條生產發布流水線放入兩個候選池，並以相同提交驗收。若固定環境、私網或簽名任務無法通過新版託管鏡像，才評估按週、月或季交付的專用遠端 Mac 節點；香港地區的 Mac 租賃選項可作為企業評估交付地點與連線路徑時的參考。

macOS-14 下線後，全面依賴新版託管鏡像的缺點是工具鏈控制較弱、私網整合受限，而且每次 Job 重建都可能增加環境驗證工作；全面自購 Mac 的缺點則是資產折舊、故障備援、閒置容量和硬體維護責任都由企業承擔。對只在遷移窗口、發布高峰或短期專案需要固定 Mac 的團隊，SFTPMAC 的遠端 Mac 租賃可提供按周期交付的真實 Mac 主機，讓企業先完成專用節點 PoC，再決定是否長期採購；但長期高負載且需要實體介面的團隊，仍應把自購硬體與現場維運納入比較。

最後更新於 2026 年 9 月 20 日；停用時間、brownout、鏡像標籤、Apple Silicon 與 Xcode 27 狀態已按 Microsoft Learn 及官方 runner-images 清單核實，正式切換前仍應再次複核。