mcpField
A
asc-release-flow

asc-release-flow

github.com/rorkaiクラウド・DevOps1.1k8.3k 回インストール2 日前に更新
リポジトリ

asc-release-flow について

App Store のバージョン準備から審査提出までを進めるワークフローガイドです。メタデータとビルドのステージング、IPA のアップロードやローカルビルド、変更前の検証を扱います。

主な機能

  1. 01メタデータのステージングとビルド添付
  2. 02IPA のアップロードまたはローカルビルド
  3. 03リリース準備状況の検証
  4. 04準備済みバージョンの審査提出
  5. 05複数項目の提出準備

活用シーン

  1. 01既存ビルドへのバージョンメタデータ設定
  2. 02IPA の公開と審査提出
  3. 03IAP や Game Center 項目を含むバージョンの準備

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/rorkai/app-store-connect-cli-skills --skill asc-release-flow

インストール後、Claude Code で/asc-release-flowを入力して読み込まれたか確認します。

同梱ファイルreferences/multi-item-submissions.md

詳細

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-id "BUILD_ID" \
  --metadata-dir "./metadata" \
  --dry-run \
  --output table

確認済みのプランを適用します。

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

--metadata-dir には、app-info/ と version/<version>/ を含む正規のメタデータルートを指定します。これは asc metadata push --dir と同じレイアウトです。ローカライズメタデータを引き継ぐ場合は、--metadata-dir の代わりに --copy-metadata-from "1.2.2" を使用します。警告をステージング失敗として扱う場合は、--strict-validate を追加します。

メタデータのプランに削除が含まれている場合、ドライランと確認済みの実行の両方で --allow-deletes が必要です。まず削除内容を確認してください。このフラグを指定すると、ローカルに存在しないロケールに対して既存のロケールへフォールバックする動作も無効になります。

リリースにルーティングアプリの対象範囲が含まれる場合は、--routing-coverage-file "./coverage.geojson" を使用します。この実験的な手順では、変更前に GeoJSON を検証し、準備状況の確認前にステージングします。

構造化出力では、steps[] の先頭に validate_build ステップが含まれます。ステップは配列内の位置ではなく、名前で照合してください。

準備済みのバージョンを提出する

メタデータ、審査の詳細、配信可能地域、ビルド処理、製品の準備状況がすでに確定している場合は、asc review submit を使用します。

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

正確なバージョン ID がわかっている場合は、--version の代わりに --version-id "VERSION_ID" を使用します。ビルドは --build-id で選択するか、ビルド ID の検索を省略するには --build-number "45" で選択します。後者は、該当するアプリ、バージョン文字列、プラットフォームのビルドのみと一致します。アップロード直後は、前回のアップロードを選ぶ可能性がある --latest よりも --build-number を優先してください。関連付けの前に処理が完了するまで待つには、--wait を追加します。

アップロードまたはビルドしてから公開する

リリースを 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

ローカルビルドモードでは、--ipa の代わりに --scheme とともに --workspace または --project を指定します。バージョンを確保した後、公開コマンドで正規のバージョンメタデータを適用する場合は、--metadata-dir を使用します。

ユーザーがアップロードと関連付けのみを希望する場合は、--submit を省略します。

複数の審査項目を提出する

アプリのバージョンを、バージョン指定の IAP、サブスクリプション、サブスクリプショングループ、または Game Center 項目とともにリリースする必要がある場合は、references/multi-item-submissions.md を参照してください。ユーザーが対応を済ませ、内容を確認した項目のみ追加してください。

提出後の引き継ぎ

以下を報告します。

  • アプリ、バージョン、プラットフォーム、ビルド、提出 ID
  • 実行されたレーンと、その完了状況
  • ユーザーの許可のもとで実行した変更
  • 提出状況を監視するための正確なコマンド

監視、キャンセル、却下理由の診断、再試行の判断には asc-submission-health を使用します。

ガードレール

  • 削除済みの submit-preflight、submit-create、release-run ショートカットは使用しないでください。
  • ドライランのプランが依頼されたリリース内容と一致するまで、--confirm を追加しないでください。
  • そのバージョンの審査提出がすでに存在する場合、2つ目の審査提出を作成しないでください。
  • 検証失敗を部分的なリリースに置き換えないでください。失敗したゲートで停止してください。
  • コマンドを自動化でラップする場合、データは stdout に、診断メッセージは stderr に出力してください。

コメント

Markdown 対応