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

一般的なCapgoセットアップでは 開発 運用 運用 チャンネル。CIはOTAバンドルをアップロードし、 dev次に、 production あなたが準備ができたときにプロモーションします。 チームはよく --fail-on-incompatible 新しいネイティブcodeが必要なライブアップデートをCIが間違って配信しないようにするため

このページは、 次の質問に答えます: あなたは 意図的に

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 を始めてください。完全なCIブランチでOTAと__CAPGO_KEEP_0__ビルドを自動的に選択するには、.

推奨チャネルレイアウト

このガイドでは、 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 (フラグを維持する)

毎日OTA (フラグを維持する)セクション

ターミナルウィンドウ

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 はアップロードごとに必要になります。チャンネルがこの戦略を使用する場合、以下の推奨事項に従ってください。チャンネルがまだ設定されていない場合は、まだ省略できます。 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)

セクションのタイトル「意図的なネイティブのバンプ（フラグを一度落とす）」

コンテキスト:Capgoマーケティングウェブサイトの長いUI文字列（親キー`you_definition`）のHTMLテキストフラグメント。ページ/エリア:Capgoマーケティングウェブサイト。役割:長いマーケティングまたは法的文章。表示される場所:ページディスクリーマー.astro、ページリターン.astro。メッセージキー`you_definition`（あなたの定義）。 できない 新しいネイティブ code を必要とするバンドルをアップロードしながら --fail-on-incompatibleその旗は、目的でプラグイン、Capacitor バージョン、または他のネイティブ依存関係が変更された場合にのみ存在します:

1. 目的でプラグイン、__CAPGO_KEEP_0__ バージョン、または他のネイティブ依存関係が変更された場合: 新しいネイティブバイナリを配信する アプリストア/プレイストア、または Capgo ビルド).
2. 新しいネイティブバイナリにマッチした JS バンドルをアップロードする --fail-on-incompatible.
3. 新しいネイティブバイナリにマッチした --auto-min-update-version チャンネルを metadata 戦略に設定することで、古いバイナリにまだいるデバイスが新しいバンドルを受信するのを防ぎます。
4. そのベースラインアップロード後、 --fail-on-incompatible 通常のOTA CIに戻す (そして続けて) --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. ネイティブバイナリを配信する

   iOS/Androidアプリをビルドして提出する

3. 新しいプラグインやネイティブの変更を含む --fail-on-incompatible)

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

   このチャンネルに新しいネイティブパッケージを記録します。後で bundle releaseType / --fail-on-incompatible チェックはその基準を使用します。

4. OTA アップロードを再開する

   次の JS-only リリースでは、両方のフラグを再び使用します:

   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 そして推定できるnative-incompatible bundleをプッシュするか?」 --auto-min-update-version いいえ。アップロードのnativeパッケージがチャンネルのライブバンドルと異なると、フラグはコマンドを故意に失敗させる。意図的なnativeバージョンアップの場合、フラグをそのアップロードに省略してください（そして

フラグを使用してください）。

はい。新しいバイナリを出荷した後、チャンネルのnative基準を進めるには、チャンネルのnative基準を進めるためのサポートされた方法です。フラグを他のOTAアップロードに残してください。そうしないと、CIで意図しないnativeの漂流が失敗することはありません。

アップロード先はどちらか? dev 最初に、次に production?

はい、もしそのプロセスに合致する場合は、同じルールを適用します。 各チャネルごとに:互換性のチェックは、対象チャネルにライブしているものに基づいて行われます。プロモーションまたは再アップロードは、チャンネルごとに production 見栄えが良ければ、native-baseline アップロード (flag を含まず) を実行し、各チャンネルで新しい native パッケージを記録します。 dev 新しい native バンドルをアップロードした場合、フラグが残っている場合どうなる? --fail-on-incompatible「新しい native バンドルをアップロードした場合、フラグが残っている場合どうなる?」

CI が失敗し、__CAPGO_KEEP_0__ がそのアップロードを配信しない。そうするのは期待どおりです。変更は意図せずに加えた場合 (native パッケージを修正し、再度 OTA でアップロードする)、または意図的に加えた場合 (上記の native パスを使用する) です。

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 が正しいパスを選択するようにします。

バージョン対象

Page/area: Capgo の解決策マーケティングページ。役割: セクションまたはページヘッダー。見られる場所: page solutions/version-targeting.astro。メッセージキー `solutions_version_targeting_title` (解決策バージョン対象タイトル)。 | Page/area: 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 または Native CI ブランチングのために バージョン目標設定 context Capgo CLI bundle reference メタデータフロアのために、そしてアップロードフラグのために