チャンネル

このプラグインのインストール手順とフルマークダウンガイドを含むセットアッププロンプトをコピーします。

Live Update チャンネルは、任意のデバイスがそのチャンネルに接続して更新を待っている場合に、特定のJSバンドルビルドを指します。Live Updates __CAPGO_KEEP_1__ をアプリにインストールすると、チャンネルに接続されているネイティブバイナリは、アプリ起動時に利用可能な更新をチェックします。チャンネルが指すビルドをいつでも変更でき、必要に応じて前のビルドに戻すこともできます。 install the Capgo Live Updates SDK __CAPGO_KEEP_0__

チャンネルはアップデートの有効性を制御しますが、バンドルの秘密性を制御するものではありません。チャンネルがプライベートであるか、または自己割り当てが無効である場合でも、Capgo にアップロードされた未暗号化のバンドルは依然として、クライアントに配布される公的資産として扱う必要があります。暗号化は配信パスと更新の有効性を保護しますが、配布されたバンドルは、クライアントの公開鍵を使用して十分な努力を払えば、配布されたアプリから逆エンジニアリングできます。詳細は「Live Update encryption」を参照してください。デバイスがチャンネルを選択する方法 (優先順位)

デバイスがアップデートを確認するとき、__CAPGO_KEEP_0__ はこの厳格な順序 (優先順位が高い順) でチャンネルを選択します。

– 特定のデバイスIDをチャンネルに固定する。緊急のデバッグまたは制御されたテストに使用する。常に勝つ。Capgo は最後のoverride書き込み後90日でマッピングを削除します。詳細は「Console and Capgo overrides expire after 90 days」を参照してください。

Cloud override (per-device) via Dashboard or __CAPGO_KEEP_0__ – ダッシュボードまたはCapgoでデバイスのチャンネルを変更すると作成されます。QAユーザーが機能/PRチャンネル間で切り替えるか、ユーザー問題を再現するために使用します。バイナリを再インストールしてもクリアされません。デバイスのoverrideを削除するとクリアされます。同様に90日間の保持期間が適用されます。 Console and API overrides expire after 90 days.
Cloud override (per-device) via Dashboard or API – Created when you change the device’s channel in the dashboard or via API. Use for QA users switching between feature / PR channels or to reproduce a user issue. Reinstalling the binary does not clear it; deleting the device override does. The same 90-day retention applies.
プラグイン setChannel() ローカルチャネル – アプリが呼び出すと作成されます。 setChannel() バックエンドがターゲットチャネルが自己割り当てを許可するかどうかを検証し、選択したチャネルはそのデバイス上でローカルに保存され、即効果を発揮し、デバイスオーバーライド UI に表示されません。

プラグインバージョン 5.34.0、6.34.0、7.34.0、または 8.0.0 (メジャーバージョンに応じて) から始めて (依存する場合) setChannel() バックエンドに接続してチャネルの有効性を検証し、自己割り当てがそのチャネルに有効かどうかを確認し、チャネルをローカルに保存します __CAPGO_KEEP_0__ __CAPGO_KEEP_1__ __CAPGO_KEEP_2__ as defaultChannel. この新しいチャンネルは、更新の確認の次のステップで即座に効果を発揮します—リプリカシオンの待機はありません。 instantly 以前は

チャンネルオーバーライドをバックエンドデータベースに保存し (例: ダッシュボードまたは__CAPGO_KEEP_0__の変更)、デバイスはデータのリプリカシオンの待機 (最大 2 分) が終わるまで新しいチャンネルが認識されるまで待ちました。新しい動作は、バックエンドからのみ読み取り (検証用) して、ローカルに保存するため、チャンネル切り替えは即座です。 setChannel() saved the channel override to the backend database (like Dashboard or API changes), and devices had to wait for data replication (up to 2 minutes) before the new channel was recognized. The new behavior only reads from the backend (for validation) and stores locally, making channel switches instant.

ローカルなので、__CAPGO_KEEP_0__ ダッシュボードにデバイスオーバーライドエントリを作成しません。デバイスオーバーライド UI は、ダッシュボードまたはパブリック__CAPGO_KEEP_1__からのみオーバーライドを表示します。 setChannel() Note: チャンネルがローカルに設定された後でも、バックエンドが更新の確認中にチャンネルを検証するため、セキュリティは維持されます。 create a Device Override entry in the Capgo dashboard. The Device Override UI only shows overrides created from the dashboard or the Public API.

text text

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

Capacitor設定 defaultChannel (テストビルドのデフォルト) – __CAPGO_KEEP_0__に存在し、強制/オーバーライド/ローカルチャンネルが存在しない場合、アプリケーションはこのチャンネルから起動します (例: ). capacitor.config.* テストフライト/内部ビルド用に設計されており、テスターは自動的にプレリリースチャンネルにアクセスします。生産ビルドでは通常、この設定を空白にします。 beta, qa, pr-123クラウドデフォルトチャンネル (主なパス ~99% のユーザー)
– ダッシュボードでデフォルトチャンネルをマークした場合、通常のエンドユーザー (強制なし、ダッシュボード/ __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日間の最後のオーバーライド書き込み後. チャンネル更新のチェックインはそのタイムスタンプをリセットしない。オーバーライドを書き直す（または自分で削除する）ことだけがタイムスタンプを変更する。

This is not the same as デバイスインベントリの保持. Inventory removes devices that have not connected to Capgo for 90 days. Override cleanup removes the mapping even if the device is still active.

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

Set defaultChannel in capacitor.config.* (再インストールで残る;後で変更するには新しいネイティブバイナリが必要)。
Call setChannel() コンテキスト:Capgo UIの長い文字列から切り取られたHTMLテキストフラグメント (親キー`appflow_migration_step2`). ページ/エリア:Appflow比較/移行マーケティングコピー。役割:ウェブサイトコピーの文。見つける場所:ionic-appflow.astroページ。 setChannel() アプリから。プラグイン5.34.0 / 6.34.0 / 7.34.0 / 8.0.0以降の場合、その割り当てはローカルであり、このクリーンアップによって削除されない。アプリを再インストールすると、クリアされるため、アプリは再び呼び出す必要がある。

__CAPGO_KEEP_0__ チャンネル デバイス タブとデバイスオーバーライドUIのみ、コンソールとパブリック API アサインメントをリストします。これらは、チャンネル上のすべてのデバイスをリストせず、またローカル API アサインメントもリストしません。 setChannel() __CAPGO_KEEP_0__ チャンネルデバイスタブに表示されるオーバーライドの保持ポップオーバー: コンソールオーバーライドは90日後に期限切れ

Capgo チャンネルデバイスタブに表示されるオーバーライドの保持通知 — デフォルトのチャンネル動作

セクション「デフォルトのチャンネル動作」

1つのデフォルト（最も一般的なケース） defaultChannel in the Capacitor config will receive updates. When you do choose to mark defaults, keep these patterns in mind:

__CAPGO_KEEP_0__ config __CAPGO_KEEP_0__ assignments
プラットフォーム固有のデフォルト – プラットフォームごとにチャンネルを分割する場合 (例えば、iOSのみ有効の場合、Androidのみ有効の場合、Electronのみ有効の場合)、それぞれのプラットフォームのデフォルトとしてマークします。 iOSデバイスはiOSのデフォルトに、AndroidデバイスはAndroidのデフォルトに、ElectronアプリはElectronのデフォルトにアクセスします。 ios-production クラウドデフォルトと両方が同じ決定層を占めていることを思い出してください。クラウドデフォルトを設定すると、__CAPGO_KEEP_0__ 設定に値を複製する必要がなくなります—生産ビルドの場合、空白のままにします。テスターまたはQAに意図的にビンナリを送信したい場合は、非生産チャンネルに始まるように予約します。クラウドデフォルトが異なる場合でも。 android-production デフォルトをいつでもダッシュボードで変更できます。チャンネルを開き、Manage in App設定をクリックしてください electron-production –

両方 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 QA defaultChannel 非生産チャンネル

Manage in App設定 生産ビルド、をクリックするとアプリ情報。デフォルトはチャンネルページでなくなる。デフォルトを入れ替えると、新しいデバイスは即座に新しいルーティングに従い、既存のデバイスはチェックインの次の時点で通常の優先順位ルールに従う。

チャンネルの設定

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

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

チャンネル名はあなたが好きなものにできます。一般的な戦略は、開発段階にチャンネルをマッチさせることです。たとえば:

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 プロジェクトにコピーします。構成の同期をスキップすると、以前の設定に従ってネイティブプロジェクトが使用されるため、ネイティブプロジェクトは以前の設定に従って使用されます。

チャンネル選択順序: 強制 > ダッシュボード/API デバイスオーバーライド > プラグイン setChannel() ローカルチャンネル > 設定 > Cloud Default。 defaultChannel 内部テスト用にのみ使用してください。プロダクションでは、ユーザーが Cloud Default (設定されている場合) に従うのではなく、ネイティブの構成にルーティングを複製するのを避けるために、省略してください。

デバイスを強制 (固定) したり、オーバーライドを適用したりすることはまだできます。それらは、構成値を即座に上書きします。 defaultChannel 使用

プロダクションビルドでは省略してください。

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

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

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

デフォルトチャンネル: 新しいデバイスが接続したときに、チャンネルまたはプラットフォーム固有のチャンネルをオプションで指定できます。コンソールでは、App Information(アプリ設定で管理 チャンネルページから)にあります。詳細は「デフォルトチャンネル動作」で確認してください。
プラットフォームフィルタ: チャンネルごとに、__CAPGO_KEEP_0__、__CAPGO_KEEP_1__、または__CAPGO_KEEP_2__に更新を配信することを許可または禁止できます。 iOS, Android自動ダウングレードを無効にする: デバイスのネイティブアプリのバージョンがチャンネルのバンドルよりも新しい場合に、更新を送信しないようにします (例えば、デバイスが1.2.3のバージョンで、チャンネルが1.2.2のバンドルを持っている場合)。 Electron 開発用ビルドを許可する: 開発用ビルドに更新を許可します (テストに便利です)。__CAPGO_KEEP_0__:
__CAPGO_KEEP_0__
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.
デバイスの自己割り当ての許可: アプリが実行時、このチャンネルに切り替えることができます。有効にしないと、 setChannelこのチャンネルでは失敗します。 __CAPGO_KEEP_0__: setChannel will fail for this channel. CLI: --self-assign / --no-self-assign.
）。ご覧ください。all, zip, delta, zip_from_builtin, delta_from_builtinパッケージの更新コンソールのドロップダウンと各モードがどのように役立つかについては、進歩的なロールアウト

「進歩的なロールアウト」のセクション

チャンネルは、デバイスの固有の基準よりも高いメジャーバージョンのターゲットバンドルをブロックすることで、安定したバンドルを維持しながら、ステイシーコホートに別のロールアウトターゲットを徐々に公開できます。すべてのユーザーにチャンネルを切り替えることなく、更新を一時停止、再開、昇格、ロールバック、自動失敗応答の自動構成を行うことができます。進歩的なロールアウト for the delivery model, dashboard workflow, API fields, and CLI commands.

自動更新戦略の無効

このオプションを使用して、チャンネルが自動的に配信する更新の種類を制限します。オプション:

メジャー: デバイスの固有の基準よりも高いメジャーバージョンのターゲットバンドルをブロックします。version_build例: 1.2.3 -> 2.0.0 許可されていません。 1.2.3 -> 1.9.0 許可されます。
マイナー: メジャーまたはマイナーバージョンが異なるターゲットバンドルをブロックします。 version_build例: 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() 呼び出される:

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

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

ダッシュボードの可視性: プラグインで設定したチャネルは、Capgo UIでデバイスオーバーライドとして表示されません。ダッシュボードまたはPublic 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 の場合でも同じ機能を含みます)。参照: プラグインのインストール

バージョンタグについて。

To deploy a live update, you need to upload a new JS bundle build and assign it to a channel. You can do this in one step with the Capgo CLI:

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

コピーする (クリップボードにコピーする)。 Development チャンネル。そのチャンネルに接続されているアプリは、次回の更新をチェックするときにアップデートを受け取る。

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

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

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

バンドルバージョンを設定する際は、 semantic versioning with Capgo’s Semver Tester のセムバーターアイテムを使用することをお勧めします。 1.2.3-beta.1.

例えば、ベータリリースの場合、バージョンは npx @capgo/cli@latest bundle upload --auto-bump CI では、ローカルバージョンが既にアップロードされている場合、 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 with no previous Capgo version). You cannot combine it with --bundleとを参照してください。と CLI reference.

このアプローチにはいくつかの利点があります:

ビルド間の関係を明確に伝えることができます。 1.2.3-beta.1 は明らかに 1.2.3.
のプレリリースです。
バージョン番号をチャンネル間で再利用できるため、混乱を減らすことができます。 1.2.3明確なロールバックパスを提供します。必要に応じて 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など

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

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

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

チャンネル名をクリック
戻したいビルドを探し、王冠アイコンをクリック
確認

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

自動デプロイ

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

チェックアウト CI/CD統合 Capgoの自動化についてもっと学びたい場合は、ドキュメントを参照してください。

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

使用する アプリプレビュー API キーを使用して、CI がプルリクビューごとに一時的なチャンネルを 1 つ作成する必要がある場合、既存のメイン/デフォルトチャンネルの管理は行わないでください。キーは所有する組織と選択したアプリと結びついており、単に組織全体の役割を持ちません。各非公開のプレビューチャンネルは、チャンネルスコープのライフサイクル権限が自動的に付与されます。

組織管理者がプレビューアプリに限定された安全なAPI キーを作成し、選択 アプリプレビュー参照してください API キー.
独自の非公開チャンネルを使用してください pr-123パブリックチャンネルを使用しないでください --default, --self-assignロールアウトオプションを渡さないでください --delete-linked-bundle-on-upload.
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.

デバイスへの展開

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

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

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

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

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

異なるユーザータイプ向けの機能フラグ
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.