2026-04-28 App Store 分階段發布、TestFlight「建置列車」，以及在香港／日本／韓國／新加坡／美國租用 Apple Silicon 雲端 Mac 上的上線檢查清單
行動發布經理若在新加坡或東京以SSH 連進租用的 Mac mini M4 跑 xcodebuild archive，往往同時面對兩套「慢」系統：TestFlight（beta、測試者與建置處理），以及App Store的客戶更新路徑（分階段或一次性）。Apple 的App Store 更新分階段上架——常被描述為對自動更新客戶約七日內按比例爬坡——並不是 TestFlight 功能，但值班手冊、Slack 狀態頻道與 Git 標籤仍需對齊。本篇 2026-04-28 手冊：(1) 劃分 TestFlight 內／外圈與 App Store 產品版本職責；(2) 釐清建置列車工件（同一提交 → 同一 CFBundleVersion／建置號家族）請勿意外分叉；(3) 提供可與既有 IPA 匯出 + App Store Connect API自動化並列紀錄的數位化清單。若要證明分階段上架的二進位即為受測二進位，可併讀 無頭 Archive + 簽章與 xcodebuild 涵蓋率門檻。
TestFlight 與 App Store：兩種受眾，一條工具鏈
TestFlight 是產品與 QA 向人類證明行為的地方（先內測再外測），Apple 的處理佇列、權限與輸出合規中繼資料仍在故事裡。App Store客戶更新——無論一次全部或分階段——面向店面中的版本紀錄，而非 beta 計畫。經典維運錯誤：啟用分階段 App Store 的同時，行銷仍指向某組TestFlight 建置號，而該號在該列車語境下永不會以上架敘述出現在店面。解法是用詞：請在工單中明確寫「TF 建置」對照「商店版本 3.2.1 (8)」。
- TestFlight — 常見計畫中外測可達一百到一萬名測試者；快速迭代當機與回饋，再把勝出建置推向發布。
- App Store — App Store Connect 中的產品版本 + 建置配對成為客戶更新；分階段發布決定該更新在一週內如何觸及自動更新客戶。
七日 App Store 分階段模型（關鍵數字）
Apple 公開的分階段行程會逐日提高自動更新客戶比例；手動更新使用者與新安裝者往往立即取得最新，因此支援話術需涵蓋兩種受眾。許多團隊的操作節奏：第 0 天 開啟分階段並監看不當機工作階段；第 1–2 天 大流量回饋最快；到第 3–4 天應觀察工單是否被舊版 iOS切片主導，而非意外的權限回退。暫停是一級狀態——把暫停當正式事件：紀錄核准者、時間長度與 App Store Connect UI／API 證據。
租用的建置主機仍須完成的責任
App Store分階段狀態機不會取代您在可信主機上歸檔、匯出與簽章IPA 的義務。租用的Mac mini M4（HK／JP／KR／SG／US）仍是編譯真值：您在 依工作釘選 Xcode 中驗證的codesign身分，以及 匯出手冊中的ExportOptions.plist選擇，務必在任何分階段開關之前由 App Store Connect 正確吸收。
真實團隊的「建置列車」：一位車長，不要三位
把建置列車想成：某產品線的候選發佈序列呈線性排列，而且同一時間最多只能有一個候選「搭上」App Store。分散式團隊的失敗模式：兩位發布經理在同一天上傳不同IPA，只因為發布分支與 hotfix 分支在各自 Runner 上都綠。2026年在繁忙SSH主機上最小可行的紀律：每次觸發 Archive 的 release/x.y合併都必須在單次 CI 門檻提交裡調高 CFBundleVersion——精神與您在用的 自架 Runner衛生一致。
git tag v3.2.1-build-4821
# 同一標籤綁到 ASC 建置紀錄與 CI 記錄工件儲存路徑
矩陣一覽：從 CI 綠燈到「客戶能更新」
| 通路 | 證明什麼 | 典型門檻 |
|---|---|---|
| PR CI（模擬器 + 單元測試） | 在釘選 SDK 上的編譯與測試 | 紅線即阻擋合併；參考 無頭測試與 涵蓋率門檻 |
| TestFlight 內測 | 冒煙、權健全性、人工關鍵路徑 | 外擴前在同一建置連續兩個工作日夜間穩定 |
| TestFlight 外測 | 更廣裝置矩陣 + App Review 中繼資料 | 分批測試者；第一道指標無閃退率 >99.0% |
| App Store（分階段或全部） | 店面列表 + 法律 + 區域定價 | 值班與 PM 簽核回滾與暫停劇本 |
九步手冊：週二歸檔 → 週五穩定
- 凍結分支 — 封版後請勿順手調 CocoaPods 或 SwiftPM 解析；複習 快取紀律。
- 於發布標籤跑 Archive — 在租用的Mac上記錄
xcodebuild -version並執行 簽章預檢。 - 匯出 IPA — 採已審查的
ExportOptions.plist，依 匯出指南 經 API 上傳——CI請避免隨機 Transporter。 - 追蹤處理 — 在 App Store Connect 監看；在日誌橋接輸出
buildProcessingState等到 Slack；遇ITMS-類別錯誤務必帶原始 JSON 秒速失敗。 - TestFlight 先內測；蒐集兩個工作日的當機日誌且無 sev-2尖峰。
- 外測族群附書面測試說明（尤其針對十四天首次安裝族群）。
- App Store版本：附上更新說明、若需要則附截圖差異，再依承受風險選分階段或立即。
- 開啟分階段：定義誰可暫停（需來自不同團隊的兩組金鑰）、可接受的最長暫停時間（並在文件中引用Apple三十日上限語境）、以及何時「向所有使用者發布」。
- 發布後：若第二天無閃退率相對基線偏離超過 0.3%就做檢討——常見是權限差異而非「新加坡特別倒霉」。
App Store Connect API、維運儀表板與稽核證據
偏自動化的團隊在2026年不會同樣的 UI 盯三次；會用 CI 文件中已載明的 JWT金鑰拉取版本資源，並把phased release state對應到儀表板。長期能力是：在合法合規前提下把API 金鑰角色收斂至最窄、與CI 簽章憑證同週期輪替，並且永不要把金鑰寫進共享SSH使用者 shell 歷程——這與 無頭簽章及 存取型態文章同源。若暫無法接 API只讀，至少 nightly 將 ASC UI 快照到工件桶，讓稽核有帶時間戳記的 PNG。
常見問題：不必問五個人就知道是否在分階段
| 問題 | 2026-04-28務實回覆 |
|---|---|
| 進行中的分階段裡穿插熱修——接下來怎辦？ | 先停：閱讀Apple目前指引（舊帖可能在政策調整之前）；實務常需新版 app 並決定是否在飛行中的列車先踩煞車——記錄決策，別對第二個建置號賭運氣。 |
| 小型區域分階段覆蓋會不同嗎？ | 使用者數視 app 而不同；重度在地化時仍應區域監控閃退與卡頓——HK／JP／KR／SG／US是 MacXCode 常見共置，可對齊測試者與審查預期。 |
為何 Apple Silicon Mac mini M4 仍出現在這個故事裡
發布速度取決於多快信任最後綠線：區域內裸機Mac mini M4帶來可預期的 xcodebuild時間、對大型.xcarchive樹狀結構誠實的磁碟 I/O，以及在 App Store Connect 看到位元組之前對程式碼簽章可信的計時——全程如此。虛擬或共享 Runner 仍可運作；但若週五活動仰賴凌晨三點UTC的分階段波次外加首爾同仁盯 crash，那么編譯主機的活動元件越少越好，才不用狂開 VNC。MacXCode 在香港、東京、首爾、新加坡與美國的1–2 TB節點，是為了讓您的發布分支敘事與分階段客戶敘事不必在周五晚搶同一顆NVMe。
