CI 已能選到 xcode-27，團隊卻還未決定是否把正式發布搬過去。
最快的做法：本週先開隔離試點，驗證工具鏈、專案相容性、任務穩定性及回退流程；試點通過前，正式發布留在已驗收的節點。
企業 IT 負責人：需要替 GitHub Actions 的 macOS 建置資源訂出准入條件。
平台工程負責人：需要核對 Runner、工作流程、第三方 Action 與專案依賴。
iOS 技術負責人：需要判斷建置、測試、簽署與發布要分階段遷移，還是暫時維持現況。
時效核對：最後更新於 2026 年 10 月 7 日；狀態核對自 GitHub Enterprise Cloud 官方 Runner 選擇文件。發布前請重新檢查標籤狀態與當期支援說明。
SECTION 01 生產准入：標籤可選不等於企業已驗收
GitHub 官方文件目前把標準 macOS Runner 的 xcode-27 標為 Public preview。這代表工作流程可以依文件指定該標籤，不代表 GitHub 已替你的專案、發布流程或企業服務要求作出適用保證；「先隔離試點、保留回退」是風險管理建議，不是官方承諾。請以官方 Runner 標籤與選擇方式說明及發布時有效的服務條款為準。
判斷時要拆開三件事：Runner 標籤是否存在、任務能否在該環境執行、該環境是否符合你的生產准入政策。只有前兩項成立，不能直接推導第三項成立。特別是 iOS 發布工作流程還可能涉及簽署資產、核准流程及產物存取；編譯成功只證明其中一段能執行，並不等於完整發布鏈路已通過。
本週建議先做基線紀錄：選一個影響範圍可控的非關鍵工作流程，記下提交識別、Runner 標籤、Xcode 選擇方式、依賴鎖定狀態、測試結果與產物識別。基線未完成前，不要以一次綠燈作為遷移依據。
SECTION 02 可重現性：把同一提交變成可比較的證據
生產驗收首先要能回答：試點節點與現有節點處理同一提交時，差異是否可追查？如果只留一張成功截圖，卻沒有建置日誌、測試結果和產物識別，之後即使結果不同，也難以分清原因來自 Runner、工具鏈還是依賴狀態。
檢查工作流程是否明確選定所需 Xcode，並保存選擇方式及執行紀錄；同時固定專案的依賴解析狀態，避免建置時重新解析套件而引入未記錄變動。Apple 的CI 中建置 Swift 套件或使用套件的應用指南可作為核對建置流程的官方依據，但實際可重現性仍須由你的專案紀錄證明。
建議用這些項目建立可稽核基線：
- 提交與環境：保留提交識別、Runner 標籤、Xcode 選擇方式及工作流程版本。
- 依賴與工具：記錄套件解析檔、第三方 Action 版本、命令列工具與必要外掛的安裝方式。
- 結果與產物：留存建置及測試日誌、失敗原因、產物識別與保存位置。GitHub 的工作流程產物說明列出產物在工作流程中的保存與取用方式；你仍需確認團隊的保存政策符合內部要求。
- 對照條件：讓既有節點和試點節點使用同一提交及可比對的工作流程輸入；遇到差異先分類，不要直接歸因於 Runner。
SECTION 03 專案相容性：逐項驗證 Action 與二進位依賴
不要把某個範例專案能跑，當成所有 iOS 專案都已相容。企業的工作流程可能同時調用第三方 Action、命令列工具、Xcode 外掛、私有套件及預編譯依賴；安裝方法、執行架構或本機狀態不同，都可能使同一套流程在新 Runner 上出現差異。
在真實專案副本中按清單核查：
- 列出 workflow 直接及間接呼叫的 Action，確認版本固定方式、維護責任與權限需求。
- 核對命令列工具及外掛是從哪裡安裝、是否依賴特定主機路徑或預先存在的設定。
- 檢查套件鎖定、二進位依賴及建置腳本是否假設特定架構或工具版本；不能確認的項目要實際跑過。
- 對每個不相容或尚未確認的元件，記錄影響任務、替代方法、負責人和復核條件。
Apple 的應用程式測試版與正式發行文件可協助區分建置與分發相關步驟。驗收時應把建置、測試、歸檔和分發分開記錄，避免只看編譯是否成功。
SECTION 04 任務分流：先遷移可隔離、容易回退的工作
企業 iOS CI Runner 選型不應只看標籤或單次建置結果，而要看任務影響面、所需控制權和失敗後的恢復方式。GitHub 的托管 Runner 參考文件適合用來核對托管 Runner 的使用資訊；你的工作負載是否滿足企業要求，則要以實際試點和內部政策判定。
| 選項 | 適合承接的任務 | 生產決策條件 |
|---|---|---|
| 現有已驗收節點 | 正式簽署、發布及失敗後影響較大的任務 | 保留作為基準與回退目標；變更需走現有審核流程。 |
| xcode-27 預覽 Runner | 可隔離、可重跑的 PR 建置或非關鍵測試 | 先比對同一提交的日誌、測試結果與產物；證據不足就不擴大任務範圍。 |
| 自管 Mac 節點 | 需要自行控制主機環境或內部作業流程的任務 | 評估維護責任、權限管理與節點可用狀態；不要只因控制面較多，就假設營運成本較低。 |
遷移順序以失敗成本由低至高安排：先挑可隔離的 PR 建置，再驗證測試及歸檔，最後才評估簽署與正式發布。需要團隊專屬本機狀態、受控簽名資產或人工核准的工作，應獨立驗收，不要與一般編譯任務共用「已通過」結論。
SECTION 05 運行與安全：以團隊紀錄替代猜測
目前不應用沒有來源的效能、排隊時間或可用率數字來判斷 xcode-27。公開文件可說明 Runner 的選用方式和安全控制概念，但排隊情況、失敗類型、重試結果及你的任務穩定性，必須從試點紀錄得出。
在試點期間，按每次執行記錄成功或失敗、失敗分類、重試結果、排隊狀況及影響範圍；觀察到的現象只能代表你測過的任務和期間，不可外推成普遍服務水準。核對倉庫授權、Runner 群組、工作流程憑證及產物存取規則，確認執行身分只拿到完成任務所需的權限。
GitHub 的安全使用 Actions 指南說明工作流程安全注意事項；Runner 群組文件則可供核對群組存取控制。另應檢查 workflow 權限設定與 Action 來源，參考工作流程語法文件。網路連線是驗收項目之一，但不能取代權限、憑證與產物邊界檢查。
SECTION 06 回退里程碑：讓每個准入結論都有負責人
試點開始前先寫下回退觸發條件、決策負責人與復核要求。若失敗只能靠臨時改 YAML、人工找產物或補登發布核准，回退便未經驗收；也不應在這種狀態下把正式任務切過去。
可用以下判定表作為准入紀錄：
- 繼續試點：基線、相容性或安全證據仍有缺口，但任務可隔離；負責人列出待補項及復核條件，正式發布維持原節點。
- 限定任務放量：特定任務已有可比較的建置、測試與產物紀錄，權限範圍清楚且切回流程實測可行；只放行已驗收的任務類別。
- 維持雙軌：部分任務適合新 Runner，簽署或發布任務仍需既有節點；分別維護兩邊的結果與產物追蹤，直到未驗收項目有結論。
- 暫緩採用：出現未解決的相容性、權限或回退問題，或無法確認測試結果及發布紀錄完整；恢復已驗收流程，修正後再安排試點。
回退驗收要實際切回既有節點，並確認必要測試有執行、建置產物仍可辨識和取得、發布審批紀錄沒有中斷。GitHub 的工作流程產物文件可協助核對產物流程，但產物的保留及存取是否符合你的政策，仍需由團隊實測確認。
FAQ
xcode-27 Runner 可以直接用於正式生產建置嗎？
官方目前標示 Public preview；這不等於任何企業工作負載已獲生產適用保證。先以隔離任務驗證完整鏈路，未完成驗收前，正式發布留在已驗收節點。
xcode-27 和穩定版 macOS Runner 應如何分配任務？
先把可重跑、非關鍵任務放入試點；高影響的簽署與發布流程維持原節點。按任務逐類比較相同提交的結果，再依證據擴大範圍。
啟用前要驗證哪些專案相容性？
核對 Actions、命令列工具、外掛、套件鎖定、預編譯依賴及架構假設。使用真實專案副本跑建置、測試與歸檔，對不確定的元件留下替代方案。
試點失敗後如何回到原有構建節點？
預先保留可切回的工作流程路徑，並記錄提交、測試、產物和核准狀態。回退後逐項確認記錄完整；由指定負責人決定何時重新試點。
若你正在比較現有托管 Runner 與 Mac 節點，前者可能受環境控制範圍及任務排隊狀況影響，後者則要自行承擔硬體採購、維護和閒置成本；兩者都不該在缺乏團隊紀錄時被假設為更穩或更便宜。先對照生產任務清單與節點驗收紀錄；若你需要臨時隔離的 Mac 測試資源，且不要求長期固定主機或實體介面，可進一步核對 VPSNIX 的方案資訊及使用與支援說明，再判斷是否適合作為補充節點。