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 上。