チャンネル

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

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

チャンネルの活用例

チャンネルとは、アップデートを指し示す名前付きのポインタだと考えてください： 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+ プラグインのメジャーバージョンに対して適用されます。旧バージョンではバックエンドのオーバーライドを書き込んでいましたが、現在の割り当てはコンソールおよび API のオーバーライド保持ルールに従います。.

テスターがアプリ内でベータアップデートを有効にします。アプリは CapacitorUpdater.setChannel({ channel: 'beta', triggerAutoUpdate: true })を呼び出します。Capgo は、 beta がデバイスのセルフアサインを許可しているか確認し、その後プラグインは将来のアップデート確認のためにその選択をローカルに保存します。他のデバイスは既存のルーティングを維持します。

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

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

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

Capgo コンソールで、 アプリアプリを選択し、 デバイスデバイスを選択して、その Channel override を変更します。 まで devCapgo は、そのデバイスを devへルーティングします。アプリのクラウドのデフォルトは production.

コンソールのデバイス override ビデオをダウンロード (MP4).

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

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

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

デバイスによるチャンネルの選択プロセス（優先順位）

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

デバイスへの強制マッピング (Dashboard) – 特定のデバイスIDをチャンネルに手動で固定します。緊急のデバッグや、特定のユーザーによる制御されたテストに使用してください。これが最優先されます。Capgo は、最後に上書きが行われてから90日後にこのマッピングを削除します。詳細は Console および API の上書き設定の有効期限は90日です.
Cloud 上書き (デバイスごと) - Dashboard または API 経由 – Dashboard または 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 (テストビルドのデフォルト) – If present in capacitor.config.* かつ force/override/local チャンネルが存在しない場合、アプリはこのチャンネルで起動します（例: beta, qa, pr-123）。これは TestFlight や内部ビルド向けで、テスターが自動的にプレリリース用チャンネルに接続されるようにするためのものです。通常、プロダクションビルドではこの設定は行いません。
Cloud Default Channel (ユーザーの約99%が利用するメインパス) – ダッシュボードでデフォルトチャンネルを指定すると、すべての一般ユーザー（force、Dashboard/API による override、プラグインの local チャンネル、config の defaultChannel がない場合）がここに接続されます。これを利用すれば、新しいバイナリを配布することなく、即座にロールアウトやロールバックが可能です。プラットフォーム固有のデフォルト（例：iOS用、Android用、Electron用など）を設定している場合、各デバイスは自身のプラットフォームに一致するデフォルトに接続されます。Cloud Default を未設定にすることも可能ですが、その場合はアップデートを受け取るためにステップ1〜4の条件を満たす必要があります。

ベストプラクティス:

Treat 1–4 as exception / testing layers; when you set a cloud default, real users should flow into it. If you choose not to set one, be deliberate about how users attach (typically via defaultChannel in config またはデバイスごとの override を使用します。
テスター向けに明示的に配布するバイナリにのみ、 defaultChannel を設定してください。未設定のままにしておくことで、プロダクションのロジックをダッシュボードで一元管理できます。
使用する setChannel() 本番環境での使用は控え、主にQAや特定の診断目的で使用してください。

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

概要: Force > Dashboard/API Override > Plugin setChannel() ローカルチャンネル > Config defaultChannel > Cloud Default。

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

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

これは以下とは異なります：デバイスインベントリの保持期間Inventoryは90日間Capgoに接続されていないデバイスを削除します。Override cleanupを使用すると、デバイスがアクティブな状態でもマッピングを削除できます。

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

設定 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 デフォルトでは trueOSがアプリデータを復元した場合にのみ、再インストール後も割り当てが保持されます。 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 を、クラウドのデフォルト設定とは異なる非本番用チャンネルから開始させたいバイナリに対してのみ使用してください。

デフォルト設定はダッシュボードからいつでも変更可能です。対象のチャンネルを開き、 アプリ設定から管理、これによって移動しますアプリ情報。デフォルト設定は、チャンネルページ上のトグル形式ではなくなりました。デフォルトを切り替えると、新しいデバイスは即座に新しいルーティングに従い、既存のデバイスは次回のチェックイン時に通常の優先順位ルールに従います。

チャンネルの設定

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

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

チャンネル名は自由に設定できます。一般的な戦略として、以下のように開発ステージに合わせてチャンネルを分ける方法があります：

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

アプリでのChannel設定

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

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

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

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

デフォルトチャンネル: 新しいデバイスが接続するチャンネル、またはプラットフォーム固有のチャンネルを任意で指定できます。コンソールでは App Information 内にあります（App設定で管理 チャンネルページから設定）。ルーティングのシナリオについては「Default Channel Behavior」を参照してください。
プラットフォームフィルター: 以下の配信を有効または無効にします： iOS, Android、または Electron チャンネルごとのデバイス。
Native Buildでの自動ダウングレードを無効化: デバイスのネイティブアプリのバージョンがチャンネルの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に最小アップデートバージョンのメタデータを必須にします。CLI を使用して --min-update-version または --auto-min-update-versionで設定してください。設定されていない場合、チャンネルは設定ミスとみなされ、設定されるまでアップデートは拒否されます。
none: Allow all updates according to semver 互換性.

これらの戦略では、送信されたネイティブのベースラインと、チャネルのターゲット bundle を比較します。 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() バックエンドから（バリデーションのために）読み取った後、ローカルに保存するため、チャンネルの切り替えが即座に行われます。

Dashboardでの表示について： プラグインで設定されたチャンネルは、Capgo UI上でDevice Overrideとして表示されません。そこにリストされるのは、dashboardまたはPublic APIから作成されたチャンネル割り当てのみです。管理者から見える上書き設定が必要な場合は、dashboardまたはAPIを使用してください。

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

チャンネル変更手法の比較：

メソッド	反映時間	保存先	デバイス上書き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のバージョニングとChannel

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

bundleのバージョニングには、以下を使用することをお勧めします。 CapgoのSemver Testerを使用したセマンティックバージョニングおよび、channel固有のbuild用のプリリリース識別子です。例えば、ベータ版は次のようにバージョン付けできます。 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 is obviously a pre-release of 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プレビュー

Use an アプリプレビュー API key を使用してください。このkeyは所有組織と選択されたアプリに紐付いたまま、組織全体へのロールは持ちません。作成される各非公開プレビューチャンネルには、チャンネルスコープ内で自動的にライフサイクル権限が付与されます。

組織の管理者に、プレビュー用アプリに限定されたセキュアな API key を作成してもらい、以下を選択してください アプリプレビュー。詳細は API キー.
以下のような、公開されていない一意のチャンネルを使用してください： pr-123を渡さないでください。 --default, --self-assign、ロールアウトオプション、または --delete-linked-bundle-on-upload.
PR bundleのアップロードとプロモートを1つのコマンドで行い、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をアップロードしてプロモートするまでの一連の流れを自動化します。クリーンアップはアトミックかつ所有権チェックが行われます。つまり、作成したチャンネルとその紐付けられた（共有されていない）bundleのみを削除できます。既存のメイン/デフォルトチャンネル、他のプレビューキーのチャンネル、または他のキーの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で実行し、 github.event.pull_request.head.repo.full_name == github.repository.

を使用して同一リポジトリ内のPRのみに制限してください。

チャンネルの仕組みを理解したところで、次は実際のデバイスへの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 を使用した Staging の実践的なコンテキストとして。