asc-release-flow

App Store 發佈協調

使用此技能將發佈從已核准的計畫推進到 App Store 審查。將 Game Center 項目準備保留在此處；將其他阻礙診斷與審查復原保留在 asc-submission-health 中。

職責邊界

此技能負責：

• 建立中繼資料並附加建構；
• 發佈 IPA 或在本機建構；
• 提交已準備好的版本；
• 組裝多項目審查提交。

使用準備章節處理 Game Center 項目準備或附加阻礙。僅在應用程式版本已建立且選擇多項目通道後，才使用該參考文件的組裝與提交章節。對於其他驗證阻礙、卡住的提交、取消或重試決策，請停止並使用 asc-submission-health。

前置條件

• 解析 APP_ID、版本字串、必要時的 VERSION_ID，以及建構已存在時的 BUILD_ID。
• 使用 asc auth login 或 ASC_* 環境變數設定驗證。
• 確認目標平台。除非應用程式針對其他平台，否則使用 IOS。
• 當工作流程套用中繼資料時，將標準中繼資料保留在 ./metadata 中。
• 在執行會變更的高階指令前要求試執行，然後要求 --confirm 以進行提交。

選擇發佈通道

意圖	指令
準備中繼資料並附加現有建構但不提交	asc release stage
提交已準備好的版本	asc review submit
上傳 IPA 或在本機建構，然後選擇性提交	asc publish appstore
提交包含 IAP、訂閱或 Game Center 版本項目的應用程式版本	較低層級的 asc review 提交指令

在一個通道已建立審查提交後，不要混合使用其他通道。先檢查現有提交，然後透過對應的較低層級指令繼續。

執行就緒檢查

將此檢查套用於已附加目標建構的版本。對於建立通道，先完成建立現有建構；asc release stage 會附加建構並執行驗證，之後即可評估此檢查。不要將預期的「建構未附加」結果導向 asc-submission-health。

在任何提交前進行驗證：

asc validate --app "APP_ID" --version "1.2.3" --platform IOS --output table

當警告必須停止自動化時使用嚴格模式：

asc validate --app "APP_ID" --version "1.2.3" --platform IOS --strict --output table

數位商品是硬性檢查。如果發佈包含 IAP 或訂閱，請停止並在 asc-submission-health 中執行相關產品檢查。僅在這些檢查沒有阻礙問題且目標產品版本已準備好後，才恢復此流程。

對於 Game Center 項目，僅完成準備每個項目，然後返回此流程。在就緒檢查期間不要組裝或提交多項目審查提交。

如果應用程式驗證報告 Game Center 項目阻礙，請停止並使用該準備章節。如果唯一的阻礙是建立通道中未附加的建構，請繼續進行建立章節。對於所有其他阻礙，請停止發佈流程並使用 asc-submission-health。不要在發佈執行中埋入不相關的補救措施。

建立現有建構

使用 asc release stage 來確保版本、套用或複製中繼資料、附加選定的建構，並執行驗證，而不建立審查提交。

預覽中繼資料驅動的建立：

asc release stage \
  --app "APP_ID" \
  --version "1.2.3" \
  --build "BUILD_ID" \
  --metadata-dir "./metadata/version/1.2.3" \
  --dry-run \
  --output table

套用已審查的計畫：

asc release stage \
  --app "APP_ID" \
  --version "1.2.3" \
  --build "BUILD_ID" \
  --metadata-dir "./metadata/version/1.2.3" \
  --confirm

當要沿用在地化中繼資料時，使用 --copy-metadata-from "1.2.2" 代替 --metadata-dir。當警告應導致建立失敗時，加入 --strict-validate。

提交已準備好的版本

在中繼資料、審查詳細資訊、可用性、建構處理及產品就緒都已解決後，使用 asc review submit。

asc review submit --app "APP_ID" --version "1.2.3" --build "BUILD_ID" --dry-run --output table
asc review submit --app "APP_ID" --version "1.2.3" --build "BUILD_ID" --confirm

當確切版本 ID 已知時，使用 --version-id "VERSION_ID" 代替 --version。僅在目標建構已附加並驗證時，才能省略 --build。

上傳或建構，然後發佈

當發佈從 IPA 或本機 Xcode 專案/工作區開始時，使用 asc publish appstore。

預覽 IPA 上傳與提交：

asc publish appstore \
  --app "APP_ID" \
  --ipa "./App.ipa" \
  --version "1.2.3" \
  --submit \
  --dry-run \
  --output table

在審查計畫後執行：

asc publish appstore \
  --app "APP_ID" \
  --ipa "./App.ipa" \
  --version "1.2.3" \
  --submit \
  --wait \
  --confirm

對於本機建構模式，提供 --workspace 或 --project 搭配 --scheme 代替 --ipa。當發佈指令應在確保版本後套用標準版本中繼資料時，使用 --metadata-dir。

當使用者僅想上傳與附加時，省略 --submit。

提交多個審查項目

當應用程式版本必須附帶有版本的 IAP、訂閱、訂閱群組或 Game Center 項目時，請閱讀 references/multi-item-submissions.md。僅加入使用者已解決並檢查過的項目。

提交後的交接

報告：

• 應用程式、版本、平台、建構及提交 ID；
• 執行了哪個通道及其是否完成；
• 使用者確認的每個變更；
• 用於監控結果提交的確切指令。

使用 asc-submission-health 進行監控、取消、拒絕診斷或重試決策。

護欄

• 不要使用已移除的 submit-preflight、submit-create 或 release-run 捷徑。
• 在試執行計畫符合要求的發佈之前，不要加入 --confirm。
• 當版本已存在一個審查提交時，不要建立第二個。
• 不要將驗證失敗變成部分發佈；在失敗的檢查點停止。
• 在包裝指令進行自動化時，將資料輸出到 stdout，診斷資訊輸出到 stderr。