チャンネル

インストール手順と、このプラグインの完全なMarkdownガイドを含むセットアッププロンプトをコピーします。

Live Update チャンネルは、アプリの特定の JS bundle ビルドを指します。このチャンネルからの更新をリッスンするように設定されたすべてのデバイスに、そのビルドが共有されます。 Capgo Live Updates SDK をインストールするアプリ内で、そのチャンネルに設定されたネイティブバイナリは、アプリの起動時に利用可能なアップデートを確認します。チャンネルが指すビルドはいつでも変更でき、必要に応じて以前のビルドにロールバックすることもできます。

簡潔に言うと： Capacitor アプリのステージングと本番環境用に、 staging と production Capgo で channel を作成し、各 bundle を staging まずアップロードしてテストし、その後同じ bundle を昇格させます。 production.

Channelsの活用例

チャンネルは、アップデートを指し示す名前付きポインタだと考えてください。 production リリース済みのアプリを配信しながら、 beta テスターに提供します。これら3つの短い動画では、デバイスがどのようにチャンネルに割り当てられるかを示しています。各動画には任意でBGMが付いていますが、ナレーションはありません。以下の説明でも同じ手順を説明します。

1. デフォルトチャンネルを使う

実行中のデバイスが v1.1.0 Capgo にアップデートをリクエストします。デバイスの割り当てやアプリで設定されたチャンネルがない場合、Capgo はクラウドのデフォルトを確認し、 production、そのアップデートを返します v1.2.0 bundle。 dev と staging 各チャンネルはこのデバイスに影響を与えずに独自のbundleを保持します。

デフォルトチャンネルの動画をダウンロード (MP4).

productionのデフォルトを設定：アプリ情報。通常のproductionビルドでは、 defaultChannel 未設定のままにしておけば、Capgo からそのルーティングを管理できます。

2. デバイスにチャンネルを選択させる

このチュートリアルでは以下を使用します： setChannel() と unsetChannel() と @capgo/capacitor-updater AndroidおよびiOSが対象です。ブラウザではこれらの方法はサポートされていません。updaterで利用可能なlocal-channelの動作を使用します。 5.34.0+, 6.34.0+, 7.34.0+、または 8.0.0+ プラグインのメジャーバージョンに対して適用されます。旧バージョンではバックエンドのオーバーライドを書き込んでいました。それらの割り当ては、 consoleおよびAPIのオーバーライド保持ルールに従います。.

テスターがアプリ内でベータ版のアップデートを有効にします。アプリは次に、 CapacitorUpdater.setChannel({ channel: 'beta', triggerAutoUpdate: true })Capgo を呼び出して、 beta デバイスのセルフアサインを許可すると、プラグインはその設定をローカルに保存し、次回以降のアップデート確認に使用します。他のデバイスは既存のルーティングを維持します。

デバイスのセルフ割り当て動画 (MP4) をダウンロード.

有効にする デバイスが自分で関連付け/解除できるようにする 使用する前に対象のチャンネルで setChannel(). このローカル設定はコンソール側の上書きを作成しません。Android および iOS（updater 8.51.0 以降）では、 persistDefaultChannelOnReinstall デフォルトでは trueに設定されます。そのため、OSがアプリデータを復元し、 persistDefaultChannelOnReinstall が残ります true。 unsetChannel() を呼び出してローカル設定をクリアします。コンソールおよび API による上書きは、引き続き以下の優先順位に従います。

3. コンソールからデバイスを1台割り当てる

Capgo コンソールで、 アプリアプリを選択し、 デバイスデバイスを選択して、その Channel override を変更します まで dev. これにより、Capgo はそのデバイスを以下へルーティングします： dev、アプリのクラウドのデフォルト設定は production.

コンソールでのデバイス上書き操作ビデオをダウンロード (MP4).

ターゲットを絞ったテストやサポートにはオーバーライドを使用します。強制マッピングがない限り、デバイスのローカルチャンネルとクラウドのデフォルトより優先されます。コンソールとAPIのオーバーライドは、最後のオーバーライド書き込みから90日後に期限切れになります.

試してみますか？コンソールでチャンネルを作成し、次に bundleをアップロードして配信されるようにします。

チャンネルはアップデートの適用対象を制御するものであり、bundleの秘匿性を保証するものではありません。チャンネルがプライベート設定であったり、セルフアサインが無効化されていたりしても、Capgoにアップロードされた暗号化されていないbundleは、クライアントに配信される公開資産として扱う必要があります。暗号化は配信経路とアップデートの真正性を保護しますが、公開鍵はクライアントに含まれているため、十分な労力をかければ配布されたアプリからbundleをリバースエンジニアリングすることは可能です。詳細は Live Updateの暗号化をご覧ください。

デバイスがチャンネルを選ぶ仕組み（優先順位）

デバイスがアップデートを確認する際、Capgo は以下の優先順位に従って使用するチャンネルを決定します（優先度の高い順）：

デバイスへの強制マッピング (Dashboard) – 特定のデバイス ID をチャンネルに手動で固定します。緊急のデバッグや、特定のユーザーによる制御されたテストに使用してください。これが最優先されます。Capgo は、最後に上書きが行われてから 90 日後にこのマッピングを削除します。詳細は ConsoleおよびAPIのオーバーライドは90日後に期限切れになります.
Dashboard または API によるクラウド上での上書き (デバイスごと) – ダッシュボードまたは API を通じてデバイスのチャンネルを変更した際に作成されます。機能検証用やPR用チャンネルを切り替えるQAユーザー、またはユーザーの問題を再現する場合に使用します。バイナリを再インストールしても保持されますが、デバイスのオーバーライドを削除するとクリアされます。90日間の保持期間は同様に適用されます。
プラグイン setChannel() ローカルチャンネル – アプリが呼び出した際に作成され、 setChannel() バックエンドが対象のチャンネルでセルフアサインが許可されているか検証します。選択されたチャンネルはそのデバイスにローカルに保存され、即座に反映されます。また、Device Override UIには表示されません。

プラグインのバージョン 5.34.0、6.34.0、7.34.0、または 8.0.0 以降 （メジャーバージョンによって異なります） setChannel() では、動作が異なります。バックエンドに問い合わせて、 検証し、 そのチャンネルが許可されているか（そのチャンネルでセルフアサインが有効か）を確認したうえで、チャンネルを デバイス上にローカル保存します。 として defaultChannelこれにより、新しいチャンネルは 即座に 次のアップデート確認で有効になります。レプリケーションを待つ必要はありません。

以前は、 setChannel() チャンネルの上書き設定をバックエンドのデータベース（DashboardやAPIの変更など）に保存していたため、新しいチャンネルが認識されるまでにデータのレプリケーション（最大2分）を待つ必要がありました。新しい動作では、バックエンドから（検証用に）読み取った後、ローカルに保存するため、チャンネルの切り替えが即座に行われます。

理由は、 setChannel() はローカルのみで完結するため、 決して Capgo dashboardにDevice Overrideのエントリを作成します。Device OverrideのUIには、dashboardまたはPublic APIから作成された上書き設定のみが表示されます。

注意: ローカルで設定した後にチャンネルが無効化されても、アップデート確認時にバックエンドがチャンネルを検証するため、セキュリティは維持されます。

重要： DashboardやAPI経由でチャンネルを変更した場合、すべてのエッジサーバーに反映されるまで最大2分のレプリケーション遅延が発生します。即座にチャンネルを切り替えるには、 setChannel() アプリからcodeを使用してください。バックエンドで検証してからチャンネルをローカルに設定するため、即座に反映されます。

Capacitor の設定 defaultChannel (テストビルドのデフォルト) – 設定されている場合 capacitor.config.* かつ、force/override/localチャンネルが存在しない場合、アプリはこのチャンネルで起動します（例: beta, qa, pr-123）。これはTestFlightや内部ビルド向けで、テスターが自動的にプレリリース用チャンネルに入るようにするためのものです。本番ビルドでは通常、この設定は未設定のままです。
Cloud Default Channel（主要経路：ユーザーの約99%） – Dashboardでデフォルトチャンネルを指定すると、すべての一般ユーザー（force、Dashboard/APIによる上書き、プラグインのローカルチャンネル、configのdefaultChannel設定がない場合）がここに接続されます。バイナリを更新することなく、即座にロールアウトやロールバックが可能です。プラットフォーム固有のデフォルト（例：iOS用、Android用、Electron用など）がある場合、各デバイスは自身のプラットフォームに一致するデフォルトに接続されます。Cloud Defaultを未設定にすることも可能ですが、その場合はアップデートを受け取るためにステップ1〜4の条件に一致する必要があります。

ベストプラクティス:

1〜4番目は例外やテスト用レイヤーとして考えてください。クラウドのデフォルトを設定した場合は、実際のユーザーがそこに流れるようにします。設定しない場合は、ユーザーがどのようにアタッチするか（通常は defaultChannel config内、またはデバイスごとのオーバーライド経由）を慎重に検討してください。
設定するのは、 defaultChannel テスター向けに明示的に配布するバイナリのみにしてください。設定しない状態にしておくことで、本番環境のロジックをダッシュボードで一元管理できます。
使用する setChannel() 本番環境での使用は最小限に留めてください。主にQAや特定の診断目的で使用します。

本来選択されるはずのチャンネルが、プラットフォーム（iOS/Android/Electronのトグル）で無効化されている場合、選択プロセスはそのチャンネルをスキップしてリストの次へ進みます。

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

ConsoleおよびAPIのオーバーライドは90日後に期限切れになります

強制マッピングや、DashboardまたはPublic API チャンネルのオーバーライドは、Capgo 内にデバイスごとの割り当てとして保存されます。クリーンアップジョブにより、これらの割り当ては削除されます。 最後のオーバーライド書き込みから90日後。アップデートのチェックインを行っても、このタイマーはリセットされません。オーバーライドを再度書き込む（または手動で削除する）ことでのみ、タイムスタンプが更新されます。

これは、以下のものとは異なります：デバイスインベントリの保持期間。インベントリは、Capgo に90日間接続されていないデバイスを削除します。一方、オーバーライドのクリーンアップは、デバイスがアクティブであってもマッピングを削除します。

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

設定 defaultChannel における capacitor.config.* (再インストール後も保持されます。後で変更するには新しい Native Build が必要です)。
呼び出す setChannel() アプリから。plugin 5.34.0 / 6.34.0 / 7.34.0 / 8.0.0 以降では、その割り当てはローカルに保持され、このクリーンアップでは削除されません。Android および iOS で updater 8.51.0 以降を使用している場合、 persistDefaultChannelOnReinstall デフォルトでは true、そのため、OSがアプリデータを復元する場合にのみ、再インストール後も割り当てが維持されます。また、 persistDefaultChannelOnReinstall が残ります true. 入力が不正な場合は、 unsetChannel() 明示的にクリアすることも可能です。

チャンネル デバイス タブとデバイスのOverride UIには、consoleとPublic APIの割り当てのみが表示されます。チャンネル上のすべてのデバイスは表示されず、ローカルの setChannel() 割り当ては表示されません。

Capgo チャンネルのDevicesタブに表示されているOverride保持期間のポップオーバー：consoleのoverrideは90日後に期限切れとなります — チャンネルのDevicesタブに表示されるOverride保持期間の通知。

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

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

単一のデフォルト（最も一般的） – チャンネルでiOS、Android、Electronが有効なら、そのチャンネルが唯一のデフォルトになります。overrideのないデバイスはすべてここに紐付きます。
プラットフォームごとのデフォルト設定 – プラットフォームごとにチャンネルを分ける場合（例： ios-production iOSのみを有効にし、 android-production Androidのみを有効にし、 electron-production Electronのみを有効にするなど）、各プラットフォームのデフォルトとして設定してください。iOSデバイスはiOSのデフォルトへ、AndroidデバイスはAndroidのデフォルトへ、ElectronアプリはElectronのデフォルトへと振り分けられます。

クラウドのデフォルト設定と defaultChannel における capacitor.config.* どちらも同じ決定レイヤーに属しています。クラウド側でデフォルトを設定していれば、Capacitor の設定ファイルに同じ値を記述する必要はありません。プロダクションビルド用には defaultChannel 空のままにしておいてください。テスターやQA向けに、 defaultChannel クラウドのデフォルト設定とは異なる非プロダクション用チャンネルから開始させたいバイナリを配布する場合に、この設定を使用します。

デフォルト設定はダッシュボードからいつでも変更可能です。対象のチャンネルを開き、 App設定で管理するには、そこから移動できますアプリ情報. デフォルトはもうチャンネルページのトグルではありません。デフォルトを切り替えると、新規デバイスはすぐに新しいルーティングに従い、既存デバイスは次回チェックイン時に通常の優先順位ルールに従います。

Channel のセットアップ

オンボーディング中に最初のチャンネル（多くのチームでは「Production」という名前）を作成しますが、制限はありません。チャンネルの名前変更や削除はいつでも可能です。後から追加のチャンネルを作成するには：

Capgo ダッシュボードの「Channels」セクションに移動します
「New Channel」ボタンをクリックします
チャンネル名を入力し、「Create」をクリックします

チャンネル名は自由に決められます。よくあるのは、開発ステージに合わせてチャンネルを分ける方法です：

Development - ローカルデバイスやエミュレータで Live Updates をテストする場合
QA - 広くリリースする前に QA チームがアップデートを確認する場合
Staging - 本番に近い環境での最終テスト用
Production - App Store等からユーザーが取得するアプリのバージョン用

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

Channelを作成したら、適切なChannelをリッスンするようにアプリを設定する必要があります。この例では、 Development アップデートを受け取ります。

を開きます capacitor.config.ts (または capacitor.config.json) ファイル。以下、 plugins セクションで、任意に設定可能です。 defaultChannel を テスト用ビルド (内部/QA用)。本番用ビルドでは、明示的に上書きしない限りデバイスが Cloud Default を使用するよう、この設定は省略することを推奨します。

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 プロジェクトにコピーします。この sync ステップをスキップすると、ネイティブプロジェクトは以前設定されていたチャンネルをそのまま使用し続けます。

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

チャンネルには、アップデートの受信対象や配信方法を制御するいくつかのオプションがあります。主要なものは以下の通りです。これらはウェブアプリ、CLI、または公開 API から設定できます。

デフォルトチャンネル: 新しいデバイスが紐付くチャンネル、またはプラットフォーム固有のチャンネルを任意で指定できます。コンソールでは App Information にあります（App設定で管理するには チャンネルページから移動してください）。ルーティングのシナリオについては「デフォルトチャンネルの動作」を参照してください。
プラットフォームフィルター: 以下への配信を有効または無効にします： iOS, Android、または Electron チャンネルごとのデバイス。
ネイティブでの自動ダウングレードを無効化: デバイスのネイティブアプリのバージョンがチャンネルのbundleよりも新しい場合に、アップデートの送信を防ぎます（例：デバイスが1.2.3で、チャンネルが1.2.2の場合）。
開発ビルドを許可: 開発ビルドへのアップデートを許可します（テストに役立ちます）。CLI: --dev / --no-dev.
本番ビルドへの適用を許可: 本番（ストア）ビルドへのアップデートを許可します。実際のユーザーが利用するチャンネルでは、これをオンにしてください。CLI: --prod / --no-prod.
エミュレータへの適用を許可: エミュレータやシミュレータへのアップデートを許可します（テストに便利です）。CLI: --emulator / --no-emulator.
実機への適用を許可: 実機のスマートフォンやタブレットへのアップデートを許可します。本番用チャンネルでは、これをオンにしてください。CLI: --device / --no-device.
デバイスによるセルフアサインを許可: アプリが実行時に以下を使用してこのチャンネルに切り替えることを許可します: setChannel. 無効にすると、 setChannel このチャンネルでの取得に失敗します。CLI: --self-assign / --no-self-assign.
ダウンロード形式: デバイスがフルZIPをダウンロードするか、変更された差分ファイルのみをダウンロードするか、あるいはその両方の最適な組み合わせを選択しますall, zip, delta, zip_from_builtin, delta_from_builtin）。参照: ダウンロード形式コンソールのドロップダウンと、各モードの使い分けについて。

段階的なロールアウト

チャンネルを使用すると、安定したbundleを維持しながら、特定のデバイスグループに対して段階的にロールアウトを行うことができます。全員のチャンネルを切り替えることなく、一時停止、再開、昇格、ロールバック、および自動失敗レスポンスの設定が可能です。詳細は段階的なロールアウト配信モデル、ダッシュボードのワークフロー、API フィールド、および CLI コマンドを参照してください。

Auto Update戦略の無効化

チャンネルが自動的に配信するアップデートの種類を制限するために使用します。オプション：

major: デバイスのネイティブベースラインよりもメジャーバージョンが高いターゲットbundleをブロックします。version_build). 例: 1.2.3 -> 2.0.0 はブロックされます。 1.2.3 -> 1.9.0 は許可されます。
minor: メジャーまたはマイナーバージョンが異なるターゲットのbundleをブロックします。 version_build. 例: 1.2.3 -> 1.3.0 はブロックされます。 1.2.3 -> 1.2.4 は許可されます。
patch: Strictest mode. Blocks any change to major, minor, or patch number. Only suffix changes are allowed while 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 はブロックされます。
metadata: 各bundleに最小アップデートバージョンのmetadataを必須にします。CLIを使用して設定します。 --min-update-version または --auto-min-update-version設定されていない場合、チャンネルは設定不備としてマークされ、設定されるまでアップデートは拒否されます。
none: 以下に従ってすべてのアップデートを許可します： semver互換性.

These strategies compare the channel’s target bundle against the native baseline sent as version_build。現在ダウンロード済みのbundleとして送信されるものではありません version_name.

詳細と例は、/docs/cli/commands/#disable-updates-strategy の 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()を使う

この @capgo/capacitor-updater メソッド setChannel() Android または iOS アプリで、実行時にプログラムからチャンネルを切り替えることができます。これは特に以下の場合に便利です。

テスターがチャンネルを切り替えられる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() チャンネルの上書き設定をバックエンドのデータベースに保存していました（DashboardやAPIの変更と同じ方式）。そのため、チャンネルの変更が反映されるまで、デバイスはバックエンドのレプリケーション（最大2分）を待つ必要がありました。現在は、 setChannel() バリデーションのためにバックエンドから読み取るだけで、設定はローカルに保存されるため、チャンネルの切り替えが即座に行えます。

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

セキュリティに関する注意: ローカルで設定した後にチャンネルの権限が変更された場合（例：セルフアサインが無効化された場合など）でも、バックエンドはアップデート確認時にチャンネルを検証するため、セキュリティは維持されます。

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

メソッド	反映時間	永続化先	Device Override UIに表示	有効期限	ユースケース
`setChannel()` プラグインから	即時	デバイスのみ（ローカル）	いいえ	自動失効なし。以下でクリア: `unsetChannel()` (再インストールで保持される場合があります)	アプリ内でのユーザーによるチャンネル切り替え
ダッシュボードでのデバイス上書き	最大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 のいずれであっても同じ機能を含みます)。詳細はプラグインのインストールのバージョンタグを参照してください。

チャンネルへのBundleの割り当て

live update をデプロイするには、新しいJS bundleビルドをアップロードし、それをチャンネルに割り当てる必要があります。Capgo CLI を使えば、これらを一度の手順で行えます:

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

これにより、ビルド済みのWebアセットがアップロードされ、新しいbundleがその Development channelの有効なビルドとして設定されます。そのchannelをリッスンするように設定されているアプリは、次回のチェック時にアップデートを受信します。

Capgo dashboardの「Bundles」セクションからも、buildをchannelに割り当てることができます。buildの横にあるメニューアイコンをクリックし、「Assign to Channel」を選択して、そのbuildに使用するchannelを選んでください。

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

Capgoにおけるbundleはアプリ全体で共有されるものであり、個別のchannelに紐付いているわけではない点に注意してください。同じbundleを複数のchannelに割り当てることが可能です。

bundleのバージョニングには、以下を使用することを推奨します： CapgoのSemver Testerを用いたセマンティックバージョニングと、チャンネル固有のビルド用のプリリリース識別子です。例えば、ベータ版は次のようにバージョン付けできます： 1.2.3-beta.1.

CIにおいて、ローカルバージョンが既にアップロードされている場合は、 npx @capgo/cli@latest bundle upload --auto-bump (任意 major, minor, patch/fix, metadata、または ai) つまり、空き名が見つかるまで、CLI はチャンネルにリンクされた bundle からバンプします。また、 ai、Workers AI はローカルと前回の差分 manifest からレベルを推論します（前回の patch Capgo バージョンがない場合はフォールバックします）。これを組み合わせることはできません --bundle。詳細は CI/CD 連携および CLI リファレンス.

このアプローチには、いくつかのメリットがあります：

ビルド間の関係を明確に伝えます。 1.2.3-beta.1 は明らかに〜のプレリリースです 1.2.3.
チャンネル間でバージョン番号を再利用でき、混乱を減らせます。
これにより、明確なロールバックパスが確保されます。もし 1.2.3からロールバックが必要になった場合、 1.2.2 が直前の安定したリリースになります。

一般的なチャンネル構成に合わせて、bundleのバージョンをどのように合わせるかの例を以下に示します：

Development channel: 1.2.3-dev.1, 1.2.3-dev.2、など。
QA channel: 1.2.3-qa.1, 1.2.3-qa.2、など。
Staging channel: 1.2.3-rc.1, 1.2.3-rc.2、など。
Production channel: 1.2.3, 1.2.4、など。

使用するプレリリース識別子付きのsemver 推奨されるアプローチですが、必須ではありません。重要なのは、ビルド同士の関係を明確に伝え、チームの開発プロセスに合うバージョニング方式を見つけることです。

Live Update のロールバック

バグが含まれていたり、元に戻す必要がある live update をデプロイした場合、以前のビルドに簡単にロールバックできます。ダッシュボードの「Channels」セクションで:

ロールバックしたいチャンネル名をクリックします
戻したいビルドを探し、王冠アイコンをクリックします
操作を確定

選択したビルドが、そのチャンネルの有効なビルドとして即座に再設定されます。アプリは、次回のアップデート確認時にロールバックされたバージョンを受け取ります。

デプロイの自動化

より高度なワークフローでは、CI/CDパイプラインの一部としてlive updateのデプロイを自動化できます。ビルドプロセスにCapgoを組み込むことで、特定のブランチへのプッシュや新しいリリースの作成に合わせて、新しいbundleのアップロードとチャンネルへの割り当てを自動で行えます。

詳細は CI/CD 連携ドキュメントでCapgo live updatesの自動化について確認してください。

最小権限のPRプレビュー

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

組織の管理者に、プレビューアプリに限定したセキュアな API キーを作成してもらい、次を選択してください： アプリプレビュー。詳細は API キー.
次のような一意の非公開チャンネルを使用してください： pr-123。以下は渡さないでください： --default, --self-assign、ロールアウトオプション、または --delete-linked-bundle-on-upload.
1つのコマンドでPRのbundleをアップロードしてpromoteし、PRがクローズしたら所有チャンネルとbundleを削除します：

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 不足しているチャンネルを作成し、bundleをアップロードして、プロモートするまでを1つのフローで実行します。クリーンアップはアトミックで、所有権チェック付きです。keyが削除できるのは、自身が作成したチャンネルと、それに紐づく共有されていないbundleだけです。既存のmain/defaultチャンネル、別のpreview keyのチャンネル、他のkeyのbundleは変更・プロモート・削除できません。

レビュアーが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.

デバイスへのデプロイ

チャンネルを理解したので、次は実機へのLive Updateのデプロイを始めましょう。基本的な流れは次のとおりです：

アプリにCapgo SDKをインストールする
指定したチャンネルをリッスンするようにアプリを設定する
ビルドをアップロードし、そのチャンネルに割り当てる
アプリを起動して、アップデートを待つ！

より詳細な手順については、以下を参照してください： Live Updatesのデプロイガイドです。スムーズなアップデートを！

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

チャンネルは開発ステージの管理だけでなく、ユーザーセグメンテーションにも活用できます。以下のような機能が実現可能です：

ユーザー層に応じたフィーチャーフラグの管理
A/Bテスト
段階的な機能のロールアウト
ベータテストプログラム

これらの高度なユースケースの実装方法は、こちらのガイドをご覧ください：フィーチャーフラグとA/Bテストに向けた、プランおよびチャンネルによるユーザーセグメンテーション方法.

Channelsの続きへ

使用している場合 チャンネル チャンネルルーティングと段階的ロールアウトを計画するには、次と組み合わせてください：チャンネル Channelsの実装の詳細については、チャンネル Channelsの実装の詳細については、ベータテストソリューション Beta Testing Solution のプロダクトワークフロー向け、バージョンターゲティングソリューション Version Targeting Solution のプロダクトワークフロー向け、および Capgo 環境のベストプラクティス：1つのモバイルアプリIDでステージング実践的な内容については、Capgo の環境ベストプラクティス「単一の Mobile App ID でのステージング」を参照してください。