チャンネル

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

ライブアップデートチャンネルは、特定のJSバンドルビルドのアプリケーションを指し、デバイスがそのチャンネルに接続してアップデートを受信する場合に共有されます。 CapgoライブアップデートのSDKをアプリケーションにインストールすると、チャンネルに接続されている任意のネイティブバイナリは、アプリケーション起動時に利用可能なアップデートをチェックします。チャンネルは機密性を提供しない

Channels control update eligibility, not bundle secrecy. Even if a channel is private or self-assignment is disabled, any unencrypted bundle uploaded to Capgo should still be treated as a public asset delivered to clients. Encryption protects the delivery path and authenticity of updates, but shipped bundles can still be reverse engineered from the distributed app with enough effort because the public key is part of the client. See Channels control update eligibility, not bundle secrecy. for details.

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

デバイスがアップデートを確認するとき、Capgoは、次の順序（優先順位が高い順）でチャンネルを選択します：

デバイスの強制マッピング（ダッシュボード） –特定のデバイスIDをチャンネルに固定する。緊急デバッグや制御テストに使用する。常に勝つ。
Cloud上のオーバーライド（デバイス単位）via ダッシュボードまたはAPI –ダッシュボードまたはAPIでデバイスのチャンネルを変更すると作成される。QAユーザーが機能/PRチャンネル間で切り替えたいときやユーザー問題を再現したいときに使用する。バイナリを再インストールしても消去されない。デバイスエントリを削除すると消去される。

プラグインバージョン5.34.0、6.34.0、7.34.0、または8.0.0から始まる (バージョンによって異なる) setChannel() targetLanguage":"Japanese","protectedTokens":["Cloudflare","Capacitor","GitHub","Capgo","code","API","SDK","CLI","npm","bun"],"texts":["","が異なる動作をします: それはバックエンドに接続し、チャンネルが許可されているかどうかを検証し (チャンネルに自己割り当てが有効になっているかどうかを確認)、次にデバイス上でチャンネルを","保存","として",". これは、次の更新チェックで新しいチャンネルが即座に効果を発揮することを意味します—リプリカシオンの待機はありません。以前は、チャンネルオーバーライドをバックエンドデータベース (例: ダッシュボードまたは__CAPGO_KEEP_0__の変更) に保存し、デバイスは新しいチャンネルが認識されるまでの最大 2 分間待機する必要がありました。新しい動作では、バックエンドからのみ読み取り (検証用) して、ローカルに保存するため、チャンネル切り替えは即座に実行されます。注意: チャンネルがローカルに設定された後でも、バックエンドが更新チェック中にチャンネルを検証するため、セキュリティは維持されます。"]} protectedTokens defaultChanneltexts targetLanguage protectedTokens

texts 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.

protectedTokens texts

Important: Dashboard または API でチャネル変更が行われた場合、エッジサーバー全体が変更を反映するまでに最大 2 分間のリプリカシオンボトルネックが発生します。即時チャネル切り替えを行うには setChannel() アプリ内から code を使用してください。バックエンドと検証し、ローカルにチャネルを設定して即効性を実現します。

Capacitor 設定 defaultChannel (テストビルドのデフォルト) – __CAPGO_KEEP_0__ が存在し、強制/オーバーライドが存在しない場合、App はこのチャネルで起動します (例えば、）。 capacitor.config.* テストフライト / 内部ビルド用に設計されており、テスターは自動的にプレリリースチャネルにアクセスします。生産ビルドは通常、この設定を空白にします。 beta, qa, pr-123Cloud Default Channel (主なパス ~99% のユーザー)
– ダッシュボードでデフォルトチャネルをマークすると、通常のエンドユーザー (強制、オーバーライド、設定のデフォルトチャネルなし) はすべてこのチャネルにアタッチされます。変更すると即時ロールアウトまたはロールバックが可能です。新しいバイナリなしです。プラットフォーム固有のデフォルト (例えば、iOS-only、Android-only、Electron-only) を設定した場合、各デバイスは対応するプラットフォームのデフォルトにアタッチされます。Cloud Default を空白にした場合は、許可されています。そうすると、デバイスはステップ 1–3 にマッチする場合にのみ更新を受け取ります。 Best practice:

ステップ 1–3 を例外 / テストレイヤーとして扱いましょう。Cloud Default を設定した場合、実ユーザーはそれに流れ込むべきです。Cloud Default を設定しない場合は、ユーザーがアタッチする方法については、意図的に考慮する必要があります (通常は、via など)。

Cloudflare defaultChannel In config またはデバイスごとのオーバーライド).
Only configure defaultChannel インビニャリーシップテスターに送る場合に限り、使用してください。生産ロジックをダッシュボードに集中させるため、未設定のままにすると便利です。
Use setChannel() 生産環境ではsparingly—QAまたはターゲット診断のために主に使用します。

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

Summary: Force > Override > Config defaultChannel > Cloud Default.

デフォルトチャネルビハビア

クラウドデフォルトを設定することは任意ですが、通常は新しいデバイスのためのキャッチオールパスとして機能します。そうでない場合、強制マッピング、オーバーライド、または「__CAPGO_KEEP_0__」設定に一致するデバイスのみがアップデートを受け取ります。クラウドデフォルトをマークする場合、次のパターンを考慮してください: defaultChannel in the Capacitor config will receive updates. When you do choose to mark defaults, keep these patterns in mind:

Single default (most common) – iOS、Android、Electronが有効なチャンネルは、デフォルトの1つになります。デバイスにoverrideが設定されていない場合はすべてここに接続されます。
Platform-specific defaults – プラットフォームごとにチャンネルを分割する場合（例えば、iOSのみ、Androidのみ、Electronのみ）、各プラットフォームごとにデフォルトを設定します。iOSデバイスはiOSデフォルトに、AndroidデバイスはAndroidデフォルトに、ElectronアプリはElectronデフォルトに接続されます。 ios-production Remember that the cloud default and android-production in electron-production both occupy the same decision layer. If you set a cloud default, you don’t need to duplicate the value in your __CAPGO_KEEP_0__ config—leave

empty for production builds. Reserve defaultChannel for binaries you intentionally ship to testers or QA when you want them to start on a non-production channel even if the cloud default is different. 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 –

任意の時点で、デフォルト値をダッシュボードで変更できます。デフォルト値を入れ替える際、新しいデバイスは即座に新しいルーティングに従い、既存のデバイスは次回チェックインする際に通常の優先順位ルールに従います。

チャンネルの設定

オンボーディングの際に最初のチャンネルを作成します（多くのチームは「Production」と呼びますが）、しかし何もロックされていません。チャンネル名を変更したり削除したりすることがいつでもできます。追加のチャンネルを追加するには:

「チャンネル」セクションのCapgoダッシュボードに移動してください
「新しいチャンネル」ボタンをクリックしてください
チャンネル名を入力し、「作成」ボタンをクリックしてください

チャンネル名は何でも構いません。一般的な戦略は、開発段階にチャンネルをマッチさせることです。

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

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

チャンネルを作成した後、適切なチャンネルにアプリをリスニングするように設定する必要があります。この例では、 Development channel.

ファイルを開いてください。 capacitor.config.ts (または capacitor.config.json)ファイルをオープンしてください。 plugins セクションの下で、オプションで defaultChannel をテストビルド (内部 / QA)に設定します。プロダクションビルドの場合、デフォルトのCloudを使用するようにデバイスに指示するには、明示的にオーバーライドするまで省略することをお勧めします。コピーする

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 更新されたconfigファイルをiOS、Android、Electronプロジェクトにコピーするために

__CAPGO_KEEP_0__

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

デフォルトチャンネル：新しいデバイスが接続したときにチャンネルまたはプラットフォーム固有のチャンネルをオプションで指定できます。デフォルトチャンネル動作については、ルーティングシナリオを参照してください。
プラットフォームフィルタ： iOS, Android, or Electron devices per channel.
Disable auto downgrade under native: Prevents sending an update when the device’s native app version is newer than the channel’s bundle (for example, device on 1.2.3 while channel has 1.2.2).
Allow development builds: Permit updates to development builds (useful for testing).
Allow emulator devices: Permit updates to emulators/simulators (useful for testing).
Allow device self‑assignment: Lets the app switch to this channel at runtime using setChannel. If disabled, setChannel will fail for this channel.

Disable Auto Update strategies

この設定を使用して、チャンネルが自動で配信するアップデートの種類を制限します。

メジャー: メジャー間のアップデートをブロック (0.0.0 → 1.0.0)。マイナーとパッチアップデートは許可されます。
マイナー: マイナー間のアップデートとメジャーをブロック (例：1.1.0 → 1.2.0)。パッチアップデートは許可されます。注: 0.1.0 → 1.1.0 をブロックしません。
パッチ: 非常に厳密です。同じメジャーとマイナーの内でパッチバージョンを増加させるだけを許可します。例：0.0.311 → 0.0.314 ✅、0.1.312 → 0.0.314 ❌、1.0.312 → 0.0.314 ❌。
メタデータ: バンドルの各バンドルに最低限のアップデートバージョンメタデータを要求します。CLI を使用して設定します。 --min-update-version または --auto-min-update-version。設定が欠けている場合、チャンネルは不正な状態とみなされ、更新は拒否されます。
すべてのアップデートを許可します。セマンティックバージョニングの互換性を参照してください。詳細と例については、/docs/__CAPGO_KEEP_0__/commands/#disable-updates-strategy を参照してください。.

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

例 (CLI):

# 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

Your AppからsetChannel()を使用

The 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
});

When setChannel() は呼ばれる:

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

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

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

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

方法	効果時間	保存先	使用例
`setChannel()` プラグインから	即時	デバイスのみ (ローカル)	アプリ内でユーザーがチャネルを切り替える
デバイスのオーバーライド	最大 2 分	バックエンドデータベース	特定のデバイスのために管理者が行う変更
API チャネル割り当て	最大 2 分	バックエンドデータベース	自動化されたバックエンド統合

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

ローカルのみのチャネル切り替えのための最小バージョン: 5.34.0, 6.34.0, 7.34.0、または 8.0.0 (バージョンマイナーの場合)。各メジャーバージョン番号の下の各ミニマーバージョン番号は、すべてのメジャーバージョンで同じ機能セットを表します (例: X.34.0 は、X が 5、6、7、または 8 の場合でも同じ機能セットを含みます)。プラグインのインストール for version tags.

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

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

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

アップロードされたウェブアセットと、チャンネルで新しいバンドルを有効にします。チャンネルに登録されているアプリは、更新を検出するたびにアップデートを受け取ります。 Development チャンネルにバンドルを割り当てることもできます。__CAPGO_KEEP_0__ ダッシュボードの「バンドル」セクションに移動し、メニューのアイコンをクリックし、「チャンネルに割り当てる」を選択して、チャンネルを選択してください。

You can also assign builds to channels from the “Bundles” section of the Capgo dashboard. Click the menu icon next to a build and select “Assign to Channel” to choose the channel for that build.

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

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

__CAPGO_KEEP_0__でバンドルバージョニングを行う際は、シーケンスベージョニングを使用し、CapgoのSemver テスターとプレリリース識別子を使用することをお勧めします。例えば、ベータ版リリースは 1.2.3-beta.1.

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

ビルド間の関係を明確に伝えることができます。 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など

使用 semverを使用してプレリリース識別子を指定しますは推奨アプローチですが、厳密には必要ではありません。バージョニングのスキームを探す鍵は、ビルド間の関係を明確に伝え、チームの開発プロセスと一致することです。

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

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

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

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

自動デプロイ

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

Check out the CI/CD統合ドキュメントを参照して、Capgoのライブ更新を自動化する方法を学びましょう。

デバイスへの展開

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

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

詳細なウォークスルーについては、「ライブ更新の展開」を参照してくださいドキュメントを参照して、__CAPGO_KEEP_0__のライブ更新を自動化する方法を学びましょう。 guide. Happy updating!

高度なチャネル使用方法: ユーザー分割

チャネルは開発段階のみに使用されるのではなく、より多くの用途に使用できます。ユーザー分割を可能にする強力なツールであり、以下のような機能を提供します。

異なるユーザータイプ向けの機能フラグ
A/B テスト
機能の段階的なロールアウト
ベータテストプログラム

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

チャネルから続けてください

Capgoを使用している場合 __CAPGO_KEEP_0__ チャンネルチャンネルチャンネルチャンネルベータテストソリューションベータテストソリューションバージョン目標ソリューションバージョン目標ソリューション環境ベストプラクティス: ステージングに1つのモバイルアプリIDを使用する Capgo Environment Best Practices: Staging with One Mobile App ID 実稼働環境における Capgo のベストプラクティス: 1 つのモバイルアプリ ID を使用したステージング。