チャンネル

このプラグインのインストール手順とフルマークダウンガイドを含む設定用の質問をコピーしてください。

A Live Update channel points to a specific JS bundle build of your app that will be shared with any devices configured to listen to that channel for updates. When you install the Capgo Live Updates SDK in your app, any native binary configured to that channel will check for available updates whenever the app is launched. You can change the build a channel points to at any time and can also roll back to previous builds if needed.

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

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

強制的なデバイスマッピング (ダッシュボード) –特定デバイスIDをチャンネルに固定します。緊急デバッグや制御テストに使用します。
Cloud override (per‑device) via Dashboard or API –ダッシュボードまたはAPIでデバイスのチャンネルを変更したときに作成されます。QAユーザーが機能/PRチャンネル間で切り替えたり、ユーザー問題を再現したりするために使用します。バイナリを再インストールしてもクリアされません。デバイスエントリを削除するとクリアされます。
プラグイン setChannel() ローカルチャンネル –アプリが呼び出し、バックエンドがターゲットチャンネルが自己割り当てを許可していることを検証したときに作成されます。選択したチャンネルはデバイス上でローカルに保存され、即座に効果を発揮し、デバイスオーバーライドUIに表示されません。 setChannel() setChannel()を使用した即時チャンネル切り替え

機能が異なります:バックエンドに連絡を取ります __CAPGO_KEEP_0__ setChannel() __CAPGO_KEEP_0__ 許可されているチャンネルかどうか確認し、チャンネル自体の割り当てが有効かどうか確認し、そのチャンネルを デバイス上に保存します。 つまり、 新しいチャンネルは即座に defaultChannel更新チェックの次のステップで効果を発揮します—待つ必要はありません。 以前は チャンネルオーバーライドをバックエンドデータベースに保存し (例: ダッシュボードまたは__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.

protectedTokens setChannel() targetLanguage texts Capgoのデバイスオーバーライドエントリを作成してください。デバイスオーバーライドUIは、ダッシュボードまたはパブリックAPIから作成されたオーバーライドのみを表示します。

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

重要: チャンネル変更がダッシュボードまたはAPIから行われた場合、エッジサーバー全体が変更を反映するまでの最大2分のリプリカシオンボグが発生します。即時チャンネル切り替えには setChannel() アプリからcode—バックエンドと検証し、ローカルにチャンネルを設定して即時効果を得ます。

Capacitor設定 defaultChannel (テストビルドのデフォルト) – がある場合、そして強制/オーバーライド/ローカルチャンネルが存在しない場合、アプリはこのチャンネルで起動します (例えば、) capacitor.config.* テストフライト/内部ビルド用に設計されており、テスターは自動的にプレリリースチャンネルにアクセスします。生産ビルドは通常、この値を未設定にします。 beta, qa, pr-123Cloudflareのデフォルトチャンネル (主なパス ~99% のユーザー)
Capacitor – APIでデフォルトチャンネルをマークした場合、すべての通常のエンドユーザー(強制なし、APIオーバーライドなし、プラグインローカルチャンネルなし、config defaultChannelなし)ここにアタッチします。変更すると即座にロールアウトまたはロールバックできます—新しいバイナリなし。プラットフォーム固有のデフォルトがある場合(例えば、iOSのみ、Androidのみ、Electronのみ)、各デバイスはプラットフォームに合ったデフォルトにアタッチします。クラウドデフォルトを未設定にすると許可されます; その場合、デバイスはステップ1–4にマッチする必要があります。アップデートを受け取る。

ベストプラクティス:

1–4を例外/テストレイヤーとして扱いましょう; __CAPGO_KEEP_0__を設定すると、実際のユーザーはそこに流れ込みます。__CAPGO_KEEP_0__を設定しない場合は、ユーザーがどのようにアタッチするか(通常はconfigまたはデバイスごとのオーバーライド)については、意図的に考えてください。 defaultChannel Only configure
__CAPGO_KEEP_0__を、テスターに明示的に配布するバイナリのみに設定してください。__CAPGO_KEEP_0__を未設定にすると、プロダクションロジックはデフォルトでダッシュボードに集中します。 defaultChannel __CAPGO_KEEP_0__を
生産環境ではsparingly使用してください—主にQAまたはターゲット診断用です。 setChannel() プラットフォーム(iOS/Android/Electron)でチャンネルが無効になっている場合、それが選択される場合に限り、選択プロセスはそれをスキップし、リストの次のものに進みます。

概要: 強制 > __CAPGO_KEEP_0__オーバーライド > プラグインローカルチャンネル > config

Summary: Force > Dashboard/API Override > Plugin setChannel() __CAPGO_KEEP_0__ defaultChannel __CAPGO_KEEP_0__

Default Channel Behavior

設定するのは任意ですが、デフォルトのパスは新しいデバイスのキャッチオールパスとして機能します。 defaultChannel in the Capacitor config will receive updates. When you do choose to mark defaults, keep these patterns in mind:

__CAPGO_KEEP_0__の設定に一致するデバイスのみが更新を受け取ります。 デフォルトをマークする場合、次のパターンを考慮してください:
単一のデフォルト（最も一般的なケース） – iOS、Android、Electronが有効になっているチャンネルが1つだけの場合、デフォルトになります。 ios-production プラットフォーム固有のデフォルト android-production – プラットフォームを分割する（例えばiOSのみ、Androidのみ、Electronのみ） electron-production とすると、各プラットフォームごとにデフォルトをマークします。iOSデバイスはiOSデフォルトに、AndroidデバイスはAndroidデフォルトに、ElectronアプリはElectronデフォルトにアタッチされます。

クラウドデフォルトと defaultChannel In __CAPGO_KEEP_0__、両方が同じ決定層を占めます。クラウドのデフォルトを設定すると、__CAPGO_KEEP_0__の設定に値を複製する必要がなくなります—生産用ビルドの場合は空のままにしておきます。 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 チャンネルの設定

チャンネルの設定

初期設定の際に最初のチャンネルを作成します（多くのチームは「生産用」と呼びますが、ロックはありません）。チャンネル名を変更または削除できます。追加のチャンネルを追加するには：

「新しいチャンネル」ボタンをクリックしてください。

Go to the “Channels” section of the Capgo dashboard
チャンネル名は何でもいいのですが、開発段階に合わせたチャンネル名を使用することが一般的です。例えば、以下のようなものがあります：
__CAPGO_KEEP_0__

__CAPGO_KEEP_0__

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

アプリ内でチャンネルを設定する

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

ファイルを開いてください。 capacitor.config.ts (または capacitor.config.json)ファイルを開いてください。 plugins セクションの下で、オプションで defaultChannel テスト用ビルドの場合にのみ使用してください。生産用ビルドの場合、デフォルトのCloud設定を使用するようにデバイスに指示するには、明示的にオーバーライドする必要があります。 クリップボードにコピー 次に、Webアプリをビルドし、

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.
    },
  },
};

注意 npx cap sync 注意

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

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

デフォルトチャンネル: 新しいデバイスが接続するチャンネルまたはプラットフォーム固有のチャンネルをオプションで指定できます。ルーティングシナリオについては「デフォルトチャンネル動作」を参照してください。
プラットフォームフィルタ: iOS, Androidデバイスごとにチャンネルごとに Electron ネイティブの自動ダウングレードを無効にする: デバイスのネイティブアプリのバージョンがチャンネルのバンドルバージョンよりも新しい場合に、更新を送信しないようにします (例: デバイスが 1.2.3 である場合、チャンネルが 1.2.2 である場合)。
開発用ビルドに更新を許可する: テストに便利な開発用ビルドに更新を許可します。
または
エミュレータデバイスの許可: エミュレータ/シミュレータの更新を許可 (テスト用に便利)
デバイスの自己割り当てを許可: アプリが実行時、このチャネルに切り替えることができる setChannelが無効になっている場合、 setChannel このチャネルでは失敗します。

自動更新戦略の無効化

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

メジャー: デバイスのネイティブ基準よりもメジャーバージョンが高いターゲットパッケージをブロックします (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を設定してください。これが欠けている場合、チャネルは不正設定としてマークされ、更新は拒否されます。
none: すべての更新を semver互換性.

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

詳細と例については、/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

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に保存されたチャネルオーバーライドをバックエンドデータベースに保存 (同様に、ダッシュボードまたはAPIの変更)。デバイスは、バックエンドのリプリカシオンの待機 (最大 2 分) まで、チャネル変更の効果を待たなければなりませんでした。現在は setChannel() バックエンドからのみ読み取り (検証用) して、ローカルに保存するため、チャネル切り替えは即時です。

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

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

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

方法	__CAPGO_KEEP_0__	__CAPGO_KEEP_1__	__CAPGO_KEEP_2__	__CAPGO_KEEP_3__
`setChannel()` __CAPGO_KEEP_4__	即時	デバイスのみ（ローカル）	いいえ	アプリ内でユーザーが行うチャネル切り替え
デバイスのオーバーライド画面	最大 2 分	__CAPGO_KEEP_9__	Yes	特定デバイスの管理者による変更
API チャネル割り当て	最大2分	バックエンドデータベース	Yes	自動化されたバックエンド統合

ユーザーがチャネル切り替えUIを構築する際に最良のユーザー体験を得るには、常にプラグインの setChannel() method.

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

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

ライブアップデートを展開するには、チャンネルに新しいJSバンドルビルドをアップロードし、割り当てる必要があります。Capgo CLIでこれを行うことができます。

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

このプロセスは、チャンネルに新しいバンドルを設定し、次にアプリがチェックするときにアップデートを受信するように設定します。 Development チャンネルにビルドを割り当てることもできます。

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.

チャンネルにビルドを割り当てるには、メニューのアイコンをクリックし、「チャンネルに割り当てる」を選択して、ビルドに割り当てるチャンネルを選択します。

It’s important to note that bundles in Capgo are global to your app, not specific to individual channels. The same bundle can be assigned to multiple channels.

バンドルをバージョン化する際は、 semantic versioning with Capgo’s Semver Tester このアプローチにはいくつかの利点があります。 1.2.3-beta.1.

ビルド間の関係を明確に伝えます。

は明らかに 1.2.3-beta.1 チャンネル間でバージョン番号を再利用できるため、混乱を減らします。 1.2.3.
明確なロールバックパスを提供します。ビルドから
をロールバックする必要がある場合、 1.2.3は前の安定版リリースです。 1.2.2 チャンネルセットアップの典型的な例として、バンドルバージョンをどのように合わせるかを示す例があります。

Here’s an example of how you might align your bundle versions with a typical channel setup:

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は推奨アプローチですが、厳密には必要ではありません。重要なのは、ビルド間の関係を明確に伝え、チームの開発プロセスと一致するバージョニングスキームを見つけることです。ライブアップデートを巻き戻すことができます。

ライブアップデートを巻き戻すことができます。

Live Updateをデプロイした場合、バグが入ったり、元に戻したい場合は、簡単に前のビルドにロールバックできます。ダッシュボードの「チャンネル」セクションから:

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

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

自動デプロイ

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

CI/CD統合を参照してください。 CI/CD統合を参照してください docsを参照して、Capgoのライブ更新を自動化する方法を学びましょう。

デバイスに展開する

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

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

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

高度なチャンネル使用方法：ユーザーセグメント化

チャンネルは開発段階にのみ使用されるものではありません。ユーザー分割の強力なツールであり、以下のような機能を実現します。

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

上記の高度な使用例を実装するためのガイドを参照してください。「プランとチャンネルを使用して機能フラグとA/Bテストを実行する方法」.

チャンネルから続けて

チャンネルを使用している場合 チャンネル チャンネルルーティングと段階的なロールアウトの計画、チャンネルに接続するチャンネルチャンネルチャンネルベータテストソリューションベータテストソリューションバージョン目標ソリューションバージョン目標ソリューション __CAPGO_KEEP_0__ 環境ベストプラクティス：1つのモバイルアプリIDでステージング Capgo 環境ベストプラクティス：1つのモバイルアプリIDでステージング for the practical context in Capgo Environment Best Practices: Staging with One Mobile App ID.