ネイティブ + OTA チャネル ワークフロー

一般的なCapgoセットアップでは 開発 運用 運用 チャンネル。CIはOTAバンドルをアップロードし dev, そしてCIはチャンネルの現在のネイティブパッケージと互換性のないバンドルをプロモートします。 production CIはチャンネルの現在のネイティブパッケージと互換性のないバンドルをプロモートしないようにするため、チームはCIがライブアップデートを配信する前にネイティブ__CAPGO_KEEP_0__をアップデートすることを保証します。 --fail-on-incompatible so CI cannot ship a live update that needs new native code by accident.

チャンネルの現在のネイティブパッケージと互換性のないバンドルが必要な場合に何をするか 意図的に チャンネルの現在のネイティブパッケージと互換性のないバンドルが必要な場合に何をするか チャンネルの現在のネイティブパッケージと互換性のないバンドルが必要な場合に何をするかについての詳細は、

If you need the background on why Capgo compares native packages, start with を参照してください。. For a full CI branch that picks OTA vs Capgo Build automatically, see Auto OTA or Native.

推奨チャネルレイアウト

このガイドでは、 dev と production チャンネルがすでに存在する場合、必要に応じて作成してください:

npx @capgo/cli@latest channel add production com.example.app
npx @capgo/cli@latest channel add dev com.example.app

チャネル	誰が受け取るか	通常のアップロード
dev	内部/QAビルド	JS (および意図的なネイティブベースライン) の各CIプッシュ
production	ユーザー	リリース用にアップロードされる

--fail-on-incompatible は両方のチャネルで 毎日OTAのアップロードのデフォルト値として機能します。 アップロードしているバンドル内のネイティブパッケージを、現在のチャネルで公開されているバンドルと比較します。パッケージが異なると、エラーが発生し、配信されません。

毎日OTA (フラグを保持)

JavaScriptのみの変更の場合、ネイティブパッケージがチャネルと一致する場合:

npx @capgo/cli@latest bundle upload com.example.app \
  --channel production \
  --fail-on-incompatible \
  --auto-min-update-version

--fail-on-incompatible blocks accidental native drift. --auto-min-update-version is required on every upload once the channel uses the metadata はアップロードのたびに必要になります。チャンネルがこの戦略を使用する場合、 metadata チャンネルがまだこの戦略を使用していない場合は、 --auto-min-update-version は省略できます。チャンネルを切り替えるまで待ってください。

CIゲートのオプションがあります。

npx @capgo/cli@latest bundle releaseType com.example.app --channel production
# → OTA      safe to upload with --fail-on-incompatible
# → native   stop; ship a native binary first (see below)

意図的なネイティブのバージョンアップ(フラグを一度だけ落とす)

あなたは あなたは codeをアップロードする必要がある新しいネイティブ --fail-on-incompatibleそのフラグは、目的のケースをブロックするために存在します。 プラグイン、Capacitorバージョン、または他のネイティブ依存関係が意図的に変更された場合:

1. 新しいバージョンの対応する ネイティブバイナリ (App Store / Play Store、または Capgo ビルド).
2. 対応するJSバンドルをアップロード の --fail-on-incompatible.
3. Prefer --auto-min-update-version チャンネルが metadata 戦略で、古いバイナリにまだいるデバイスが、新しいアプリをインストールするまで、新しいバンドルを受信しないようにするようにします。
4. アップロードしたベースライン後、 --fail-on-incompatible CI (通常の OTA) に戻す (そして続けて --auto-min-update-version チャンネルは続きます metadata).

1. チャンネルごとに 1 回限り: メタデータ ゲーティングを有効にします

   npx @capgo/cli@latest channel set production com.example.app --disable-auto-update metadata

   続けて dev もし、そのチャンネルも意図的にネイティブ バイナリを取得する場合。 この切り替え後、チャンネルにアップロードされるすべてのアップロードには --auto-min-update-version または --min-update-version.

2. チャンネル

   ネイティブ バイナリを配信

3. iOS/Android アプリをビルドして提出する (新しいプラグインやネイティブの変更を含む)。ユーザーがそのバイナリをインストールするまで、依存するネイティブ パッケージに依存するバンドルを安全に実行することはできません。 --fail-on-incompatible)

   npx @capgo/cli@latest bundle upload com.example.app \
     --channel production \
     --auto-min-update-version

   このチャンネルに新しいネイティブパッケージを記録します。後続のチェックでは、その基準を使用します。 bundle releaseType / --fail-on-incompatible 保護されたOTAアップロードを再開

4. 後続のJSのみリリースでは、両方のフラグを使用します:

   ターミナルウィンドウ

   npx @capgo/cli@latest bundle upload com.example.app \
     --channel production \
     --fail-on-incompatible \
     --auto-min-update-version

ネイティブ基準アップロードを、CIジョブとして専用に扱いましょう (または、手動リリースステップとして)、デフォルトのOTAジョブに例外として散らすのではなく。デフォルトのジョブは、常にアップロードを続けます。

ターミナルウィンドウ クリップボードにコピー ヒント --fail-on-incompatible、そしてその metadata チャンネルで、も同様に --auto-min-update-version.

FAQ

セクション「FAQ」 --fail-on-incompatible 「--fail-on-incompatible」を

セクション「--fail-on-incompatibleを使用せずに、native-incompatible bundleをpushすることは可能ですか？」 --auto-min-update-version いいえ。アップロードのnativeパッケージがチャンネルのライブバンドルと異なると、フラグはコマンドを故意に失敗させるように設計されています。意図的にnativeバージョンを上げる場合、そのアップロードにフラグを省略してください（そして

セクション「一時的なアップロードにフラグを省略することは正しいアプローチですか？」

context

アップロード先は開発環境から始めて、生産環境に進むか? dev 最初に、次に production?

はい、もしそのプロセスに合致する場合は、同じルールを 各チャネルごとに:互換性のチェックは、対象チャネルに現在公開されているものと比較されます。生産または再アップロードは production 正常に動作するまで待ち、ネイティブベースのアップロード ( dev )を各チャネルで実行して、ネイティブパッケージの更新を記録する。 --fail-on-incompatible新しいネイティブパッケージをアップロードした場合、フラグがまだ付いていてどうなるか?

「新しいネイティブパッケージをアップロードした場合、フラグがまだ付いていてどうなるか?」というセクション

CI fails and Capgo does not ship that upload. That is the expected outcome. Either the change was accidental (fix the native packages and retry as OTA), or it was intentional (use the native path above).

どの旗がどのジョブに?

パス	時期	旗のアップロード
OTA	JSのみ;ネイティブパッケージはチャンネルに合わせる	--fail-on-incompatible + --auto-min-update-version チャンネルが有効の場合に必要 metadata)
ネイティブベースライン	新しいネイティブバイナリ + マッチングのJSバンドル	なし --fail-on-incompatible;保持 --auto-min-update-version

関連

ネイティブ互換性

Capgo がネイティブパッケージの変化を検出する方法と、デバイスに不互換な意味

Auto OTA またはネイティブ

Wire bundle releaseType GitHub アクションまたは GitLab に入力して、CI が正しいパスを選択するようにします。

バージョン対象

ページ/エリア: Capgo のソリューションマーケティングページ。役割: セクションまたはページヘッダー。見られる場所: page solutions/version-targeting.astro。メッセージキー `solutions_version_targeting_title` (ソリューション バージョン対象タイトル)。| ページ/エリア: Capgo のソリューションマーケティングページ。役割: 短い UI ラベルまたはナビゲーションアイテム。見られる場所: page solutions/version-targeting.astro。メッセージキー `solutions_version_targeting` (ソリューション バージョン対象)。

CLI: bundle

__CAPGO_KEEP_0__: バンドル

アップロード、互換性、releaseType、および関連フラグのリファレンス

Native + OTA チャネルワークフローを使用している場合 Native + OTA チャネルワークフロー Native + OTA チャネルワークフローを安全にネイティブのリリース間でライブアップデートを維持するには、 Native Compatibility ネイティブパッケージの比較規則のために Auto OTA or Native CI ブランチングのために バージョン目標設定 コンテキスト: Capgo のソリューションマーケティングページ。役割: セクションまたはページヘッダー。見られる場所: page solutions/version-targeting.astro。メッセージキー `solutions_version_targeting_title` (ソリューション バージョン ターゲット イング タイトル)。 | コンテキスト: Capgo のソリューションマーケティングページ。役割: 短い UI ラベルまたはナビゲーションアイテム。見られる場所: page solutions/version-targeting.astro。メッセージキー `solutions_version_targeting` (ソリューション バージョン ターゲット イング)。 Capgo CLI bundle reference __CAPGO_KEEP_0__ __CAPGO_KEEP_1__ バンドル参照