CI 顯示上傳成功，但 TestFlight 找不到構建，或測試人員仍無法安裝。
最快處理方式：先在 App Store Connect 核對構建狀態，再分辨 Apple 處理、構建資格與測試組分發；不要一遇到延遲就盲目重跑 CI 或輪換簽名資產。這就是 TestFlight CI 上傳排障的起點。
企業 IT 或發布負責人：你需要制定上傳後的狀態核驗與升級流程。
CI 平台工程師：你要判斷問題發生在 Mac 構建、上傳，還是 Apple 處理階段。
QA 或測試負責人：你要確認構建已指派到正確測試組，且測試人員具備安裝條件。
SECTION 01 先分清楚「已上傳」與「可測試」是不同里程碑
CI 收到成功結果，代表流水線的上傳步驟回報已完成；它不能單獨證明 App Store Connect 已處理完構建，更不能證明測試人員已取得存取權。Apple 說明，已上傳的構建需經處理後才會顯示於 App Store Connect。上傳後的處理、構建狀態與 TestFlight 分發，是彼此相連、但不能混為一談的環節。Apple 的構建上傳說明列出上傳交付流程；構建狀態說明則說明處理後的狀態。
| 發布里程碑 | 你應核對的證據 | 仍未能證明的事 |
|---|---|---|
| CI 完成歸檔 | 產物識別資料、歸檔工作紀錄 | Apple 已收到或處理構建 |
| 上傳工具回報完成 | 工具結果、delivery log、交付狀態 | 構建已具備測試資格 |
| App Store Connect 顯示構建 | App、版本、構建識別資料與狀態 | 已指派測試組，或測試人員可安裝 |
| 測試組可見構建 | 測試組關聯、測試資訊及分發狀態 | 每位受邀者的帳號與裝置條件均符合 |
因此，第一個檢查點不是「要不要再跑一次建置」，而是「這次產物目前在哪個里程碑，有什麼紀錄可以證明」。在 App Store Connect 的構建與元資料頁面確認對應 App 與構建，再回頭比對 CI 記錄；若頁面尚無構建，才沿著上傳紀錄往回查。
SECTION 02 Apple 仍在處理時，該留下什麼證據？
若 App Store Connect 顯示仍在處理，先記錄目前狀態、構建識別資料與頁面資訊，再依團隊發布流程設定的升級路徑處理。處理時間不應被當成固定 SLA；上傳工具結束，也不等於 Apple 後端處理已完成。Apple 對構建上傳狀態及構建狀態分別提供說明，遇到狀態不一致時，應以當下頁面和交付紀錄為依據。
核對時，把兩種證據分開保存：
- CI／上傳端：工作識別資料、上傳工具結果、產物識別資料，以及可追溯的 delivery log。
- App Store Connect 端：構建是否出現、目前狀態、頁面資訊，以及狀態有變化時的更新紀錄。
如果上傳端回報完成，但 App Store Connect 尚未顯示構建，先確認上傳的是哪個 App、版本與構建，再檢查該次交付紀錄。若構建已出現但仍未進入可測試狀態，按照目前顯示的狀態繼續處理。沒有錯誤證據時，不要把再次建置當成通用解法；新產物可能只會讓後續追查多出一筆紀錄。
SECTION 03 構建資格不符時，如何避免重複提交同一個問題？
若狀態或錯誤資訊指出構建不符合上傳要求，常見排查方向包括 delivery log、包識別資料、版本與構建號，以及實際提交的產物是否符合目前要求。這些是核對項目，不代表每次都能據此預判拒絕原因。具體原因應以 App Store Connect 當下的錯誤資訊和Apple 的上傳要求為準。
請先分清兩種情形：
- 上傳階段失敗：工具回報交付未成功，從 Transporter 上傳結果或 CI delivery log 找出失敗步驟，再決定是否重傳。
- 已收到但不符合要求：Apple 已接收構建，卻指出構建資格有問題。保留錯誤內容，回查產物與設定，修正後重新歸檔並交付。
- 構建已可見但未能分發：上傳與構建資格不再是首要疑點，應轉查測試組、測試資訊與人員邀請。
相同產物若沒有任何內容或設定變更，重複提交不會替它修正錯誤。也不要在沒有簽名問題證據時輪換憑證或簽名資產：這會改變排查變數，未必能解決構建資格或分發設定問題。
SECTION 04 構建可見，測試組與安裝端還要核對什麼？
構建已出現在 App Store Connect，不代表所有測試人員都已獲得存取權。先確認平台與目標構建，再查構建是否指派至預期測試組、測試資訊是否完整，以及當前分發流程是否要求額外處理。Apple 的TestFlight 概覽與測試人員分配說明可用來核對目前的測試流程；內部測試人員則應依Apple 的內部測試說明檢查。
外部測試與內部測試的流程並不完全相同。不要只憑團隊過往的操作記憶判定已具備分發條件，而要查看目前介面對該構建、測試組及測試人員顯示的要求。
若構建與測試組關聯正確，仍無法安裝，逐項查核邀請是否送達、測試人員是否使用符合資格的帳號，以及測試端顯示的具體提示。若只有個別人員遇到問題，先對照其邀請與帳號狀態；如果整個測試組都無法安裝，再回到構建分發狀態核對。沒有證據前，不要先把問題歸咎於 Mac CI、測試裝置或網路。
SECTION 05 建立 CI 上傳後的重試與升級閉環
要讓 TestFlight CI 上傳排障可以交接與稽核，流水線應留下能把一次建置、一次上傳和一筆 App Store Connect 構建串起來的資訊。建議保存構建識別資料、上傳工具結果、delivery log 的引用方式，以及 App Store Connect 最終狀態。團隊如已有發布紀錄系統，可在其中連結原始工作與核驗結果；不要只保存一張「上傳成功」的截圖。
在下一次發布任務中，按這個順序驗收：
- 歸檔階段：確認產物和識別資料符合本次發布預期。
- 交付階段：保存上傳工具結果及 delivery log，分辨上傳失敗與已完成交付。
- Apple 處理階段：在 App Store Connect 對照構建是否出現及目前狀態。
- 分發階段：確認構建已指派到預期測試組，並核對相應的測試條件。
- 測試端階段：確認測試人員能取得構建，並記錄安裝端提示；有問題時按提示回到相應環節。
採用以下條件分支決定下一步：
- 若上傳工具明確回報交付失敗，而且 delivery log 指向傳輸或交付步驟，修正該步驟後再依發布流程重試；否則保留原次紀錄，先核對 App Store Connect。
- 若構建已出現且狀態仍在處理，保存狀態和構建識別資料，按團隊既定升級規則追蹤；不要只因等待就重建或輪換簽名資產。
- 若 App Store Connect 顯示資格錯誤，先按錯誤資訊修正產物或設定，再重新歸檔與交付；不要重複提交未修改的產物。
- 若構建可測試但目標測試人員無法安裝，回查測試組、邀請、帳號及用戶端提示；若這些檢查均通過，再以具體證據升級調查 CI 節點。
| 觀察結果 | 優先處理方向 | 避免的動作 |
|---|---|---|
| 工具未確認交付完成 | 檢查工具結果與 delivery log | 只看 CI 任務整體的成功標記 |
| 構建尚未顯示或仍在處理 | 核對構建識別資料與 Apple 狀態 | 未查證就重建或重傳 |
| 顯示資格錯誤 | 依錯誤資訊回查產物與上傳要求 | 原樣重交同一產物 |
| 構建與分發條件已確認，但端點仍失敗 | 保存測試端提示並按團隊流程升級 | 預設歸因於 Mac 節點故障 |
注意：驗收標準應涵蓋「歸檔到測試組可見」的完整鏈路，而不是只看 CI 任務的綠色狀態。只有當相同環節反覆出現、且證據指向節點環境時，才把 Mac 節點納入根因分析。
若你要整理團隊的節點與存取方式，可先參考 VPSNIX 的遠端 Mac 環境方案；若需要確認服務選項，可查看方案資訊，並用說明中心核對服務與操作問題。
SECTION 06 常見問題
CI 顯示上傳完成，為什麼 TestFlight 還看不到構建？
上傳工具回報完成，只能證明該工具完成了它所回報的交付步驟，不能代替 App Store Connect 的處理狀態。先確認 CI 上傳的是預期 App 與產物，再到構建頁面核對狀態；若仍未顯示，保存 delivery log 與構建識別資料，循團隊升級流程追蹤，不要只因列表尚未更新就立即重跑建置。
App Store Connect 顯示處理中，需要重跑 CI 嗎？
不要單憑「處理中」就重跑。先確認原上傳是否已被接收、狀態是否對應預期構建，並按團隊流程記錄當下頁面資訊。若交付結果明確失敗，才處理上傳步驟；若構建已進入 Apple 處理，應追蹤狀態而非提交相同產物。處理時間不應被假設為固定 SLA。
構建已處理，測試人員仍無法安裝，先查什麼？
先查構建是否指派到正確測試組，以及目前分發頁面要求的資訊是否完整；接著核對測試人員邀請、帳號資格和用戶端提示。先從個別人員還是整個測試組都受影響，判斷問題範圍，再依證據追查。只有測試組和人員條件都確認無誤，才應把調查焦點移回 CI 節點。
如何分辨 IPA 上傳失敗、Invalid Binary 與分發故障？
查看錯誤出現的位置。上傳工具或 Transporter 回報交付失敗時，先查上傳結果與 delivery log；Apple 已收到構建但提示 Invalid Binary 時，按 App Store Connect 的錯誤資訊檢查構建資格；構建已可見而測試人員不能取得時，轉查測試組和邀請。不要用重跑 CI 一次處理這三類不同故障。
若你目前以自購 Mac 作為固定發布節點，需自行承擔硬體採購、維護及閒置容量的管理；若使用非專用的共用環境，則要留意權限邊界與發布證據是否足以追溯。對需要隔離重現問題、但不想為短期驗證新增實體設備的團隊，租用 VPSNIX 遠端 Mac 可作為比較方案；若工作負載長期固定或必須使用實體介面，則應先評估自有設備是否更合適。無論選哪種方式，都用同一套「上傳、Apple 處理、測試組可見」驗收條件檢查交付鏈路。
SECTION 07 常見問題 FAQ
TestFlight 構建上傳成功後，為什麼在 App Store Connect 看不到？
先確認上傳工具回報的是交付結果，而不是 Apple 已完成處理。到 App Store Connect 的構建與元資料頁面檢查目標 App、版本及構建識別資料，再對照上傳工具的 delivery log 和上傳狀態；若紀錄顯示仍在處理，保留該次交付證據並等待狀態更新，不要只因暫時看不到就重建或重傳。
App Store Connect 顯示處理中，CI 應該立刻重跑嗎？
通常不應只因處理中就重跑。先核對構建識別資料、上傳結果與目前狀態；若原始交付已被 Apple 接收，重跑可能只增加重複產物和追查負擔。只有交付紀錄明確顯示上傳失敗，或狀態與團隊的升級規則相符時，才依流程重試或交由發布負責人處理。
構建已處理但測試人員無法安裝，先查哪裡？
先在 App Store Connect 確認目標構建已指派到預期測試組，並檢查該組的測試資訊與目前分發條件；接著確認測試人員邀請、帳號資格和測試端顯示的提示。若其他測試人員可安裝而單一使用者不行，優先比較該使用者的邀請及帳號狀態，不要先把問題歸因於 Mac CI。
如何分辨 IPA 上傳失敗、Invalid Binary 和 TestFlight 分發問題？
IPA 上傳失敗通常要先看 Transporter 或 CI 上傳工具的交付結果及 delivery log；Invalid Binary 表示已收到的構建未符合當前上傳要求，應按 App Store Connect 顯示的錯誤回查產物；若構建可見且具備測試條件，則轉查測試組、邀請或安裝端。三者的證據位置不同，不宜用同一個重跑步驟處理。