Channels

Live Update チャンネルは、特定のJSバンドルビルドのアプリケーションを指し、デバイスがそのチャンネルに接続してアップデートを待っている場合に共有されます。アプリケーションに install the Capgo Live Updates SDK Live Updates __CAPGO_KEEP_1__

チャンネルは機密性を提供しません。

チャンネルはアップデートの有効性を制御しますが、バンドルの秘密性を制御しません。チャンネルがプライベートであるか、または自己割り当てが無効である場合でも、Capgo にアップロードされた未暗号化のバンドルは依然として、クライアントに配布されるパブリック アセットとして扱う必要があります。暗号化は配信パスと更新の有効性を保護しますが、配布されたバンドルは、クライアントのパブリック キーを使用して十分な努力を払えば、配布アプリを逆アセンブルできます。詳しくは Live Update の暗号化 を参照してください。

デバイスがチャンネルを選択する方法 (優先順位)

デバイスがアップデートをチェックするとき、Capgo は次の順序 (優先順位が高い順) でチャンネルを選択します:

1. 強制的なデバイス マッピング (ダッシュボード) – 特定のデバイス ID をチャンネルに固定します。緊急のデバッグまたは制御されたテストに使用します。1 つの実ユーザーとテストする場合に使用します。常に勝ちます。Capgo は、最後のオーバーライドの書き込みから 90 日後にマッピングを削除します。詳しくは コンソールと API のオーバーライドは 90 日後に期限切れになります.
2. クラウド オーバーライド (デバイスごと) via ダッシュボードまたは API – ダッシュボードまたは API でデバイスのチャンネルを変更すると作成されます。機能 / PR チャンネル間で QA ユーザーが切り替える場合、またはユーザー イシューを再現する場合に使用します。バイナリを再インストールするとオーバーライドはクリアされません。デバイス オーバーライドを削除するとクリアされます。同様に、90 日の保持期間が適用されます。
3. プラグイン setChannel() ローカルチャネル – アプリが呼び出すと作成されます setChannel() バックエンドがターゲットチャネルが自己割り当てを許可するかどうかを検証し、選択したチャネルはそのデバイス上でローカルに保存され、即座に有効になり、デバイスオーバーライドUIには表示されません。

setChannel()を使用した即時チャネル切り替え

プラグインバージョン 5.34.0、6.34.0、7.34.0、または 8.0.0 (メジャーバージョンに応じて) から始めて (依存するメジャーバージョンに応じて) setChannel() バックエンドに接続して 有効であることを確認します チャネルが許可されているかどうかを検証し、チャネルを デバイス上でローカルに保存します as defaultChannel. この新しいチャンネルは instantly の更新チェックの次の時点で

Previously、 setChannel() はチャンネルオーバーライドをバックエンドデータベースに保存し（ダッシュボードやAPIの変更と同様）、デバイスは2分以内にデータの再同期を待ってから新しいチャンネルが認識されるようになりました。新しい動作はバックエンドからのみ読み取り（検証用）し、ローカルに保存するため、チャンネル切り替えは即時になります。

Because setChannel() はローカル専用なので、 は__CAPGO_KEEP_0__ダッシュボードにデバイスオーバーライドエントリを作成しません。デバイスオーバーライドUIは、ダッシュボードまたはパブリック__CAPGO_KEEP_1__からのみオーバーライドを作成したものを表示します。 create a Device Override entry in the Capgo dashboard. The Device Override UI only shows overrides created from the dashboard or the Public API.

チャンネルがローカルに設定された後でも、バックエンドは更新チェック中にチャンネルを検証するため、セキュリティは維持されます。 __CAPGO_KEEP_0__

重要な注意事項: ダッシュボードまたはAPIを介してチャンネルが変更された場合、エッジサーバー全体が変更を反映するまで2分以内に遅延が発生します。即時チャンネル切り替えには setChannel() アプリケーションからcodeを使用してください。バックエンドと検証し、ローカルにチャンネルを設定して即時効果を実現します。

4. Capacitor設定 defaultChannel (テストビルドのデフォルト) – __CAPGO_KEEP_0__に存在し、強制/オーバーライド/ローカルチャンネルが存在しない場合、アプリケーションはこのチャンネルから起動します (例: ). capacitor.config.* テストフライト/内部ビルド用に設計されており、テスターは自動的にプレリリースチャンネルにアクセスします。通常、プロダクションビルドではこの設定を空白にします。 beta, qa, pr-123クラウドデフォルトチャンネル (主なパス ~99% のユーザー)
5. – ダッシュボードでデフォルトチャンネルをマークすると、通常のエンドユーザー (強制なし、ダッシュボード/ __CAPGO_KEEP_0__ オーバーライドなし、プラグインローカルチャンネルなし、config defaultChannel なし) はすべてこのチャンネルにアタッチされます。変更すると即時ロールアウトまたはロールバックが可能になります。新しいバイナリなしです。プラットフォーム固有のデフォルト (例、iOSのみ、Androidのみ、Electronのみ) を設定している場合、各デバイスは対応するプラットフォームにマッチしたデフォルトにアタッチされます。クラウドデフォルトを空白にした場合、デバイスはステップ1-4にマッチする場合にのみ更新を受け取ります。 – If you mark a default channel in the dashboard, all normal end‑users (no force, no Dashboard/API override, no plugin local channel, no config defaultChannel) attach here. Change it to roll out or roll back instantly—no new binary. If you have platform-specific defaults (for example, one iOS-only, one Android-only, one Electron-only), each device lands on the default matching its platform. Leaving the cloud default unset is allowed; in that case the device must match on steps 1–4 to receive updates.

ステップ1-4をテスト/エクスペリエンス層として扱い、クラウドデフォルトを設定した場合、実ユーザーはそれに流れ込むようにしてください。クラウドデフォルトを設定しない場合は、ユーザーがアタッチする方法については、通常は

• __CAPGO_KEEP_0__を使用してください。 defaultChannel configまたはデバイスごとのオーバーライドで設定します。
• Only configure defaultChannel テスト用にテスターに明示的に配布するバイナリのみに設定します。設定しないと、生産用ロジックはダッシュボードに集中されます。
• Use setChannel() 生産環境ではsparinglyに使用し、主にQAまたはターゲットされた診断に使用します。

プラットフォーム (iOS/Android/Electron) の設定が有効になっていない場合、選択プロセスはそのチャンネルをスキップし、リストの下に続きます。

Summary: Force > Dashboard/API Override > Plugin setChannel() ローカルチャンネル > 設定 defaultChannel > Cloud Default。

コンソールとAPIオーバーライドは90日後に期限切れになります。

強制マッピングとダッシュボードまたはパブリックAPIチャンネルオーバーライドはCapgoにデバイスごとに割り当てられます。クリーンアップジョブは割り当てを削除します。 90 日間の最後のオーバーライド書き込み後. チャンネル更新のチェックインはそのタイムスタンプをリセットしない。オーバーライドを書き直す (または自分で削除する) ことでタイムスタンプが変更される。

これは別のものである デバイスのインベントリ保持. Inventory removes devices that have not connected to Capgo for 90 days. Override cleanup removes the mapping even if the device is still active.

このクリーンアップによって削除されない割り当ての場合:

• セット defaultChannel イン capacitor.config.* (再インストールしても存続する;後で変更するには新しいネイティブバイナリが必要)
• コール setChannel() アプリから。プラグイン 5.34.0 / 6.34.0 / 7.34.0 / 8.0.0 以降の場合、その割り当てはローカルであり、このクリーンアップによって削除されない。アプリを再インストールするとクリアされるため、アプリは再び setChannel() を呼び出す必要がある。

チャンネル デバイス タブとデバイスのOverride UIのみコンソールとPublic API割り当てを表示します。 これらは、チャンネル内のすべてのデバイスを表示せず、ローカル setChannel() 割り当てを表示しません。

チャンネル デバイス タブに表示されるOverrideの保持の注意

デフォルトのチャンネル動作

クラウドのデフォルトを設定することは任意ですが、通常は新しいデバイスのキャッチオールパスとして機能します。 そうでない場合、強制マッピング、オーバーライド、または defaultChannel Capacitor の設定に一致するデバイスのみがアップデートを受け取ります。 デフォルトをマークする場合、次のパターンを考慮してください:

• シングルデフォルト（最も一般的な） – iOS、Android、Electronが有効なチャンネルがある場合、デフォルトのチャンネルになり、オーバーライドがなければデバイスはここにアタッチされます。
• プラットフォーム固有のデフォルト – プラットフォームごとにチャンネルを分割する場合 (例えば、iOSのみ有効、Androidのみ有効、Electronのみ有効)、各プラットフォームごとにデフォルトをマークします。iOSデバイスはiOSデフォルトに、AndroidデバイスはAndroidデフォルトに、ElectronアプリはElectronデフォルトにアクセスします。 ios-production iOSが有効な場合 android-production Androidが有効な場合 electron-production Electronが有効な場合

クラウドデフォルトと両方のデフォルトは同じ決定レイヤーを占めます。クラウドデフォルトを設定すると、__CAPGO_KEEP_0__ 設定に値を複製する必要がなくなります—生産用ビルドの場合に空白のままにします。テスターまたはQAに非生産用チャンネルを意図的に配布する場合にのみ、非生産用チャンネルに値を設定してください。クラウドデフォルトが異なる場合でも。 defaultChannel 生産用ビルドの場合に空白のままにします。 capacitor.config.* both occupy the same decision layer. If you set a cloud default, you don’t need to duplicate the value in your Capacitor config—leave defaultChannel クラウドデフォルトと両方のデフォルトは同じ決定レイヤーを占めます。 defaultChannel 生産用ビルドの場合に空白のままにします。

テスターまたはQAに非生産用チャンネルを意図的に配布する場合にのみ、非生産用チャンネルに値を設定してください。 クラウドデフォルトを設定すると、__CAPGO_KEEP_0__ 設定に値を複製する必要がなくなります—生産用ビルドの場合に空白のままにします。テスターまたはQAに非生産用チャンネルを意図的に配布する場合にのみ、非生産用チャンネルに値を設定してください。クラウドデフォルトが異なる場合でも。、 アプリ情報。デフォルトはチャンネルページでなくなる。デフォルトを入れ替えると、新しいデバイスは即座に新しいルーティングに従い、既存のデバイスはチェックインの次の時点で通常の優先順位ルールに従う。

チャンネルの設定

オンボーディング中、最初のチャンネル（多くのチームはそれを “Production” と名付けます）を作成しますが、まだ何もロックされていません。チャンネル名を変更したり削除したりすることがいつでもできます。追加のチャンネルを設定するには:

1. Capgo ダッシュボードの “チャンネル” セクションに移動
2. “新しいチャンネル” ボタンをクリック
3. チャンネル名を入力し “作成” をクリック

チャンネル名はあなたが好きなように自由に設定できます。一般的な戦略は、開発段階にチャンネルをマッチさせることです。

• Development - ローカルデバイスまたはエミュレータでライブアップデートをテストする
• QA - QA チームが広範なリリース前にアップデートを検証する
• Staging - 生産環境に近い環境で最終テストを行う
• Production - アプリストアからユーザーが受け取るアプリのバージョン向け

アプリ内でチャンネルの設定

チャンネルが作成されたら、アプリを適切なチャンネルに反応させるように設定する必要があります。この例では、チャンネルを使用します。 Development チャンネルを開く

ファイル (または capacitor.config.ts ) を開きます。チャンネルセクションの下で、オプションでテストビルドを capacitor.config.jsonチャンネル plugins チャンネル defaultChannel ファイル セクション (内部 / QA). 生成用ビルドの場合、Cloudflare のデフォルトを使用するようにする。デフォルトを明示的にオーバーライドしない限り。

import { CapacitorConfig } from '@capacitor/cli';

const config: CapacitorConfig = {
  plugins: {
    CapacitorUpdater: {
      // For a QA/TestFlight build – testers start on the Development channel automatically.
      defaultChannel: 'Development',
      // Production builds usually omit this so users attach to the Cloud Default channel.
    },
  },
};

次に、Web アプリをビルドし、 npx cap sync を実行して、更新された構成ファイルを iOS、Android、Electron プロジェクトにコピーします。構成の同期をスキップすると、以前の設定に従ってネイティブ プロジェクトが使用するチャネルが続きます。

注意

チャネル選択順序: 強制 > Dashboard/API デバイスオーバーライド > プラグインローカルチャネル > Config > Cloud Default。 setChannel() テスト/内部ビルドでのみ使用してください。生成用ビルドの場合、ユーザーは Cloudflare のデフォルトを使用するようにすることなく、ネイティブの構成にルーティングを複製するのを避けることができます。 defaultChannel デバイスまたはオーバーライドを強制 (固定) することはまだ可能です。それらは、構成値を即座に上書きします。

Copy to clipboard defaultChannel Channel selection order: Force > Dashboard/__CAPGO_KEEP_0__ device override > Plugin local channel > Config > Cloud Default.

Use only in test/internal builds; leave it out for production so users follow the Cloud Default (when set) instead of duplicating the routing in native config.

チャンネル名は大文字と小文字が区別されます。

チャンネルオプションと戦略

チャンネルには、更新を受け取るユーザーと更新を配信する方法を制御するオプションが複数あります。重要なものは以下のとおりです。Webアプリ、CLI、またはPublic APIから設定できます。

• デフォルトチャンネル: 新しいデバイスが接続したときに、チャンネルまたはプラットフォーム固有のチャンネルをオプションで指定できます。コンソールでは、App Information（アプリ情報）にあります。アプリ設定を管理 チャンネルページから参照してください。
• デフォルトチャンネル動作については、ルーティングシナリオを参照してください。 iOS, Androidプラットフォームフィルタ: チャンネルごとに、__CAPGO_KEEP_0__、__CAPGO_KEEP_1__、または__CAPGO_KEEP_2__に送信するデバイスを有効または無効にできます。 Electron デバイスごとにチャンネルを有効または無効にできます。
• 自動ダウングレードを無効にする: デバイスのネイティブアプリのバージョンがチャンネルのバンドルよりも新しい場合に、更新を送信しないようにします。
• Allow development builds: Permit updates to development builds (useful for testing). CLI: --dev / --no-dev.
• 生産ビルドの許可: 生産 (ストア) ビルドへの更新を許可します。 実際のユーザーにサービスを提供するチャンネルでは、この設定をオンにします。 CLI: --prod / --no-prod.
• エミュレータ デバイスの許可: エミュレータ/シミュレータ (テストに役立つ) への更新を許可します。 CLI: --emulator / --no-emulator.
• 物理デバイスの許可: 実際のスマートフォンやタブレットへの更新を許可します。 生産チャンネルでは、この設定をオンにします。 CLI: --device / --no-device.
• デバイスの自己割り当ての許可: アプリが実行時、このチャンネルに切り替えることができるようにします。 これを無効にすると、 setChannelwill fail for this channel. __CAPGO_KEEP_0__: setChannel will fail for this channel. CLI: --self-assign / --no-self-assign.
• See all, zip, delta, zip_from_builtin, delta_from_builtinUpdate package for the console dropdown and when each mode is useful. 進歩的なロールアウト

Progressive rollouts

A channel can maintain a stable bundle while gradually exposing a separate rollout target to a sticky device cohort. You can pause, resume, promote, roll back, and configure an automatic failure response without switching the channel for everyone. See Progressive rollouts for the delivery model, dashboard workflow, API fields, and CLI commands.

Progressive rollouts

Disable Auto Update strategies

• Section titled “Disable Auto Update strategies”version_buildUse this to restrict which kinds of updates the channel will automatically deliver. Options: 1.2.3 -> 2.0.0 major: Blocks a target bundle whose major version is higher than the device native baseline ( 1.2.3 -> 1.9.0 Example:
• is blocked; version_buildis allowed. 1.2.3 -> 1.3.0 ブロックされています; 1.2.3 -> 1.2.4 許可されています。
• パッチ: 最も厳格なモード。メジャー、ミニマム、パッチ番号の変更はすべてブロックされ、サフィックスの変更のみが許可されます。 MAJOR.MINOR.PATCH サフィックスの変更のみが許可されます。 1.0.0-beta.1 -> 1.0.0-beta.2 サフィックスの変更のみが許可されます。 1.0.0+build.1 -> 1.0.0+build.2 サフィックスの変更のみが許可されます。 1.0.0 -> 1.0.1 ブロックされています。
• メタデータ: 各バンドルに最低限のアップデートバージョンのメタデータが必要です。CLI を使用して設定します。 --min-update-version または --auto-min-update-version設定されていない場合、チャネルは不正設定とみなされ、更新は拒否されます。
• 許可されていない場合、更新は拒否されます。 セマンティックバージョニングの互換性に従ってすべての更新を許可します。.

これらの戦略では、チャンネルの対象バンドルを、送信されたネイティブのベースラインと比較します。 version_build、ではなく、ダウンロードした現在のバンドルを送信した version_name.

詳細と例については、/docs/cli/commands/#disable-updates-strategy を参照してください。

例 (CLI): チャンネルはすでに存在している必要があります (channel set チャンネルを作成しない):

# Block major updates on the Production channel
npx @capgo/cli@latest channel set production com.example.app \
  --disable-auto-update major

# Allow devices to self-assign to the Beta channel
npx @capgo/cli@latest channel set beta com.example.app --self-assign

# Production channel: store builds on real devices, no emulators
npx @capgo/cli@latest channel set production com.example.app --prod --device --no-emulator

アプリから setChannel() を使用する

この setChannel() メソッドは、アプリが実行時でチャンネルをプログラム的に切り替えることを可能にします。この機能は、特に以下のシナリオで便利です。

• QA/デバッグメニューでテスターがチャンネル間を切り替えることができる場合
• ベータプログラムのオプティンフロー
• 機能フラグの実装
• A/Bテストのシナリオ

import { CapacitorUpdater } from '@capgo/capacitor-updater';

// Switch to the beta channel
await CapacitorUpdater.setChannel({ channel: 'beta' });

// Optionally trigger an immediate update check after switching
await CapacitorUpdater.setChannel({
  channel: 'beta',
  triggerAutoUpdate: true
});

setChannel()のしくみ (v5.34.0+ / v6.34.0+ / v7.34.0+ / v8.0.0+)

いつ setChannel() 呼ばれる:

1. バックエンドの検証 (読み取り専用): Capgo バックエンドにリクエストが送信され、チャンネルが許可されているかどうか (自己割り当ての権限をチェック) を確認します。
2. ローカルストレージの更新: 検証が成功した場合、チャンネルはデバイスのローカルストレージに保存されます。 defaultChannel
3. 即時効果: 次のアップデートチェックでは、新しいチャネルを即座に使用します (リプリカシオンの待機なし)

なぜこれが重要か: 古いバージョンでは setChannel() 保存したチャネルオーバーライドをバックエンドデータベースに保存しました (同様に、API の変更やダッシュボードの変更も)。デバイスは、バックエンドのリプリカシオンの待機 (最大 2 分) が終了するまで、チャネル変更の効果を得ることができませんでした。現在は setChannel() バックエンドからのみ読み取り (検証用) して、ローカルに保存するため、チャネル切り替えが即時になりました。

ダッシュボードの可視性: プラグインで設定したチャネルは、Capgo UI でデバイスオーバーライドとして表示されません。ダッシュボードまたはパブリック API から作成されたチャネル割り当てのみがリストされます。ダッシュボードまたは API を使用して、管理者が表示できるオーバーライドが必要な場合は、ダッシュボードまたはパブリック API を使用してください。

セキュリティに関する注意: チャネルの権限がローカルに変更された後 (たとえば、自己割り当てが無効化された場合)、バックエンドはアップデートチェック中にチャネルの検証を実行し、セキュリティが維持されることを保証します。

チャネル変更方法の比較:

方法	効果時間	永続保存場所	デバイスオーバーライドUIで表示	有効期限	使用例
setChannel() プラグインから	即時	デバイスのみ(ローカル)	なし	変更または再インストールするまで	ユーザーがアプリ内でチャネルを切り替える
デバイスオーバーライドダッシュボード	最大 2 分	バックエンド データベース	はい	最後のオーバーライド書き込み後 90 日	特定のデバイスのための管理者が行う変更
API チャンネル割り当て	最大 2 分	バックエンド データベース	はい	最後のオーバーライド書き込み後 90 日	自動化されたバックエンド統合

チャンネル切り替え UI を構築する際に最良のユーザー エクスペリエンスを確保するには、常にプラグインを使用してください。 setChannel() メソッド。

ローカル専用チャンネル切り替えの最小バージョン: 5.34.0, 6.34.0, 7.34.0, または 8.0.0 (主バージョンに応じて)。各マイナーバージョン番号は、すべての主バージョンで同じ機能セットを表します (例: X.34.0 は、X が 5、6、7、または 8 の場合でも同じ機能を含みます)。詳しくは プラグインのインストール を参照してください。

バンドルをチャンネルに割り当てる

ライブアップデートをデプロイするには、新しいJSバンドルビルドをアップロードし、チャンネルに割り当てる必要があります。Capgo と CLI を使用して、1 つのステップで実行できます。

npx @capgo/cli@latest bundle upload --channel=Development

これにより、ビルドされたWebアセットをアップロードし、チャンネルに割り当てた新しいバンドルをアクティブなビルドとして設定します。 Development チャンネル。 そのチャンネルに接続して更新を待つアプリは、次に更新をチェックするときにその更新を受け取る。

また、チャンネルにビルドを割り当てることもできます。 “バンドル”セクションのCapgoダッシュボードのメニューアイコンの隣にあるビルドをクリックし、「チャンネルに割り当てる」を選択して、そのビルドのチャンネルを選択してください。

バンドルバージョニングとチャンネル

Capgoのバンドルは、アプリ全体にグローバルで、個々のチャンネルに特有のものではありません。 同じバンドルを複数のチャンネルに割り当てることができます。

バンドルをバージョン化する際には、 セマンティックバージョニングを使用し、CapgoのSemverテスターとプレリリース識別子を使用することをお勧めします。 プレリリースの場合、バージョンは 1.2.3-beta.1.

CIで、ローカルバージョンが既にアップロードされている場合、 npx @capgo/cli@latest bundle upload --auto-bump （任意） major, minor, patch/fix, metadata）を使用して、__CAPGO_KEEP_0__がチャンネルのリンクされたバンドルからバージョンを上げるまで、無料の名前を探します。 ai) so the CLI bumps from the channel’s linked bundle until a free name is found. With ai, Workers AI はローカル vs 前回の delta マニフェストからインファーするレベル (前回のマニフェストがない場合は) patch Capgo の前のバージョンがない場合にフォールバックします。Capgo を組み合わせることはできません。 --bundleCI/CD Integration と __CAPGO_KEEP_0__ の参照 CLI reference.

ビルド間の関係を明確に伝えることができます。

• __CAPGO_KEEP_0__ は明らかに 1.2.3-beta.1 __CAPGO_KEEP_0__ を使用して、チャンネル間でバージョン番号を再利用できるため、混乱を減らすことができます。 1.2.3.
• 明確なロールバックパスを提供します。__CAPGO_KEEP_0__ からロールバックする必要がある場合、
• を知ることができます。 1.2.3, you know 1.2.2 は、前の安定版リリースです。

ここでは、チャンネル設定の典型的な例として、バンドルバージョンを合わせる方法を示します。

• Development チャンネル: 1.2.3-dev.1, 1.2.3-dev.2など
• QA チャンネル: 1.2.3-qa.1, 1.2.3-qa.2など
• Staging チャンネル: 1.2.3-rc.1, 1.2.3-rc.2など
• Production チャンネル: 1.2.3, 1.2.4など

チャンネル: など は推奨アプローチですが、厳密には必要ではありません。重要なのは、ビルド間の関係を明確に伝え、チームの開発プロセスと一致するバージョニングスキームを見つけることです。

ライブアップデートのロールバック

バグが入ったライブアップデートや、戻す必要があるライブアップデートがあれば、簡単に前のビルドに戻すことができます。ダッシュボードの「チャンネル」セクションから:

1. チャンネルをロールバックしたい場合は、そのチャンネルの名前をクリック
2. 戻したいビルドを探し、王冠のアイコンをクリック
3. 確認

選択したビルドはすぐにそのチャンネルで有効になります。アプリは、更新をチェックするときにロールバックしたバージョンを受け取ります。

自動デプロイ

より高度なワークフローでは、ライブアップデートのデプロイをCI/CDパイプラインの一部として自動化できます。Capgoをビルドプロセスに統合すると、新しいバンドルを自動的にアップロードし、特定のブランチにプッシュしたり、新しいリリースを作成したりするたびにチャンネルに割り当てることができます。

チェックアウト CI/CD統合 Capgoの自動化について学びましょう。

最小権限のプルリクビュー

App Preview __CAPGO_KEEP_0__ キーを使用して、CI がプルリクエストごとに一時的なチャネルを 1 つ作成する必要がある場合、既存のメイン/デフォルト チャネルを管理しないようにします。このキーは所有する組織と選択したアプリと結び付けられますが、組織全体の役割を持ちません。各非公開のプレビュー チャネルは、チャネル スコープのライフサイクル パーミッションが自動的に付与されます。 組織管理者がプレビュー アプリに制限された API キーを作成し、選択

1. Have an organization administrator create a secure API key limited to the preview app and select 詳しくは__CAPGO_KEEP_0__ キー API.
2. 独自の非公開チャンネルを使用してください pr-123パブリックチャンネルを使用しないでください --default, --self-assignロールアウトオプションを渡さないでください --delete-linked-bundle-on-upload.
3. PRバンドルをアップロードしてプロモートするコマンドを1つにし、PRがクローズしたときに所有するチャンネルとバンドルを削除してください

APP_ID="com.example.app"
PREVIEW_CHANNEL="pr-123"
BUNDLE_VERSION="1.2.3-pr.123"

npx @capgo/cli@latest bundle upload "$APP_ID" \
  --apikey "$CAPGO_PREVIEW_KEY" \
  --path ./dist \
  --channel "$PREVIEW_CHANNEL" \
  --bundle "$BUNDLE_VERSION"

npx @capgo/cli@latest channel delete "$PREVIEW_CHANNEL" "$APP_ID" \
  --apikey "$CAPGO_PREVIEW_KEY" \
  --delete-bundle \
  --success-if-not-found

bundle upload --channel ターミナルウィンドウが欠けているチャンネルを作成し、バンドルをアップロードし、プロモートするフローを1つにします。クリーンアップは原子的で所有権をチェックします:キーは作成したチャンネルとリンクされた、共有されていないバンドルを削除できますが、既存のメイン/デフォルトチャンネル、別のプレビュー キーのチャンネル、または別のキーのバンドルを変更、プロモート、または削除することはできません。

レビューアがQRコードcodeまたはプレビューURLが必要な場合、管理者はアプリにプレビューを有効にする必要があります

npx @capgo/cli@latest app set "$APP_ID" --preview
npx @capgo/cli@latest get-qr "$APP_ID" --channel "$PREVIEW_CHANNEL" --apikey "$CAPGO_PREVIEW_KEY" --url

App Preview キーはプレビューを有効にすることができません。なぜなら、App Settings の権限がないからです。GitHub Actions で、秘密を含むプレビュー ジョブを実行するには pull_request、を使用しないでください pull_request_target, では、同じリポジトリの PR に制限します。 github.event.pull_request.head.repo.full_name == github.repository.

デバイスへの展開

チャンネルを理解したので、実際のデバイスにライブアップデートを展開する準備ができました。基本的なプロセスは次のとおりです。

1. アプリに Capgo SDK をインストールします
2. アプリを自分の望ましいチャンネルにリスニングするように設定します
3. ビルドをアップロードし、そのチャンネルに割り当てます
4. アプリを起動し、更新を待ちます!

詳細なウォークスルーについては、 ライブアップデートの展開 ガイドを参照してください。更新を楽しみましょう!

高度なチャンネル使用: ユーザー セグメンテーション

チャンネルは開発段階のみに使用されるのではなく、強力なツールとしてのユーザー分割に使用できます。次のような機能を実現します。

• ユーザー層ごとの機能フラグ
• A/Bテスト
• 機能ロールアウトの段階的実施
• ベータテストプログラム

これらの高度な使用例を実装する方法については、以下のガイドを参照してください。 プランとチャンネルを使用して機能フラグとA/Bテストでユーザーを分割する方法.

チャンネルから続けて

Capgoを使用している場合 チャンネル チャンネルルーティングとステージドロールアウトの計画に役立つ機能です。 チャンネル チャンネル チャンネル ベータテストソリューション ベータテストソリューションの製品ワークフロー バージョン対象ソリューション バージョン対象ソリューションの製品ワークフロー __CAPGO_KEEP_0__ 環境ベストプラクティス: ステージングに1つのモバイルアプリID Capgo 環境ベストプラクティス: ステージングに1つのモバイルアプリIDの実践的な背景 for the practical context in Capgo Environment Best Practices: Staging with One Mobile App ID.