チャンネル

ライブアップデートチャンネルは、任意のデバイスがそのチャンネルに更新を待機している場合に、特定のJSバンドルビルドを指します。チャンネルが指すビルドを変更したり、必要に応じて前のビルドに戻したりすることができます。 CapgoライブアップデートSDKをアプリにインストールすると、チャンネルに設定されている任意のネイティブバイナリは、起動時に利用可能な更新をチェックします。 チャンネルは機密性を提供しません。

__CAPGO_KEEP_0__

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 ライブアップデートの暗号化 詳細はこちら。

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

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

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

setChannel() を使用した即時チャンネル切り替え

プラグインバージョン 5.34.0、6.34.0、7.34.0、または 8.0.0 から始めて (あなたのメジャーバージョンに応じて) setChannel() バックエンドに接続してチャンネルの有効性を検証し チャンネルが許可されているかどうかを確認し、チャンネルが自分自身に割り当てられているかどうかを確認します。 そのチャンネルをローカルに保存します デバイス上のチャンネル 新しいチャンネルは即座に有効になり defaultChannel次の更新チェックから リプリカの待ちなしで 有効になります

以前は setChannel() 保存されたチャンネルオーバーライドをバックエンドデータベース (ダッシュボードやAPIの変更と同様) に保存し、デバイスはデータのレプリケーション (最大 2 分) を待つ必要がありました。新しい動作は、バックエンドからのみ読み取り (検証用) して、ローカルに保存するため、チャンネル切り替えは即時になります。

しかし setChannel() ローカルのみなので、__CAPGO_KEEP_0__ ダッシュボードにはデバイスオーバーライドエントリを作成しません。デバイスオーバーライドUIは、ダッシュボードまたはパブリック__CAPGO_KEEP_1__からのみオーバーライドを作成したものを表示します。 注意: create a Device Override entry in the Capgo dashboard. The Device Override UI only shows overrides created from the dashboard or the Public API.

重要: ダッシュボードまたは__CAPGO_KEEP_0__からチャンネル変更が行われた場合でも、エッジサーバー全体が変更を反映するまでの最大 2 分のレプリケーションラグが残ります。即時チャンネル切り替えには、

からアプリケーション__CAPGO_KEEP_0__を使用してください。バックエンドと検証し、ローカルにチャンネルを設定して即効性を実現します。 API設定 setChannel() from your app code—it validates with the backend, then sets the channel locally for immediate effect.

4. Capacitor defaultChannel テストビルド(デフォルト) – 以下の条件が満たされていれば、表示されます。 capacitor.config.* と、強制/オーバーライド/ローカルチャネルが存在しない場合、Appはこのチャネルで起動します (例えば、) beta, qa, pr-123テスト用の内部ビルド用に設計されています。テスト者は自動的にプレリリースチャネルに到達します。通常、プロダクションビルドではこの値を未設定にします。
5. クラウドデフォルトチャネル(主なパス ~99% のユーザー) – ダッシュボードでデフォルトチャネルをマークすると、すべての通常のエンドユーザー (強制なし、ダッシュボード/API オーバーライドなし、プラグインローカルチャネルなし、config defaultChannel なし) にアタッチされます。変更すると即時ロールアウトまたはロールバックが可能になります。新しいバイナリなしです。プラットフォーム固有のデフォルト (例えば、iOSのみ、Androidのみ、Electronのみ) を設定している場合、各デバイスは対応するプラットフォームのデフォルトにアタッチされます。クラウドデフォルトを未設定にすると、デバイスはステップ 1–4 にマッチしない限り、更新を受信できません。

ベストプラクティス:

• ステップ 1–4 を例外/テストレイヤーとして扱い、クラウドデフォルトを設定した場合、実ユーザーはそれに流れ込むようにしてください。クラウドデフォルトを設定しない場合は、ユーザーがアタッチする方法については、明確に決めてください (通常は) defaultChannel config またはデバイスごとのオーバーライドを使用します。
• のみをビンナリに含める defaultChannel テスト用に明示的に配布するビンナリのみに含める。クラウドデフォルトを未設定にすると、プロダクションロジックはダッシュボードに集中するので、プロダクションビルドではこの値を未設定にします。
• を使用します setChannel() 生産環境ではsparingly使用されます—主にQAまたはターゲット診断用です。

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

概要： 強制 > ダッシュボード/API Override > プラグイン setChannel() ローカルチャンネル > 設定 defaultChannel > Cloud Default。

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

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

• – iOS、Android、Electronが有効になっているチャンネルが1つだけデフォルトになり、オーバーライドなしのデバイスはここにアタッチされます。 プラットフォーム固有のデフォルト
• Platform-specific defaults – iOS と Android のプラットフォームを分割した場合 (例えば、iOS のみ有効、Android のみ有効、Electron のみ有効)、各チャネルをそれぞれのプラットフォームのデフォルトとしてマークします。 iOS デバイスは iOS のデフォルトに、Android デバイスは Android のデフォルトに、Electron アプリは Electron のデフォルトにアクセスします。 ios-production Cloudflare のデフォルトと両方が同じ決定レイヤーを占めます。Cloud のデフォルトを設定すると、__CAPGO_KEEP_0__ の設定に値を複製する必要がなくなります – これは、プロダクション ビルドの場合に空のままにしておいてください。非プロダクション チャネルにアクセスしたい場合にのみ、テスターまたは QA に送信するバイナリを予約してください。 android-production デフォルトをいつでもダッシュボードで変更できます。デフォルトを入れ替えると、新しいデバイスは新しいルーティングに即座に従い、既存のデバイスは次回チェックインするときに通常の優先順位ルールに従います。 electron-production チャンネルの設定

チャンネルの設定 defaultChannel – iOS と Android のプラットフォームを分割した場合 (例えば、iOS のみ有効、Android のみ有効、Electron のみ有効)、各チャネルをそれぞれのプラットフォームのデフォルトとしてマークします。 iOS デバイスは iOS のデフォルトに、Android デバイスは Android のデフォルトに、Electron アプリは Electron のデフォルトにアクセスします。 capacitor.config.* Cloudflare のデフォルトと両方が同じ決定レイヤーを占めます。Cloud のデフォルトを設定すると、Capacitor の設定に値を複製する必要がなくなります – これは、プロダクション ビルドの場合に空のままにしておいてください。非プロダクション チャネルにアクセスしたい場合にのみ、テスターまたは QA に送信するバイナリを予約してください。 defaultChannel デフォルトをいつでもダッシュボードで変更できます。デフォルトを入れ替えると、新しいデバイスは新しいルーティングに即座に従い、既存のデバイスは次回チェックインするときに通常の優先順位ルールに従います。 defaultChannel チャンネルの設定

チャンネルの設定

– iOS と Android のプラットフォームを分割した場合 (例えば、iOS のみ有効、Android のみ有効、Electron のみ有効)、各チャネルをそれぞれのプラットフォームのデフォルトとしてマークします。 iOS デバイスは iOS のデフォルトに、Android デバイスは Android のデフォルトに、Electron アプリは Electron のデフォルトにアクセスします。

初期設定の際に最初のチャンネル（多くのチームはそれを「Production」と名付けます）を作成しますが、何もロックされていません。チャンネルをいつでも名前を変更したり削除したりできます。追加のチャンネルを追加するには:

1. Capgo ダッシュボードの「チャンネル」セクションに移動
2. 「新しいチャンネル」ボタンをクリック
3. チャンネルの名前を入力し、「作成」ボタンをクリック

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

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

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

Configuring the Channel in Your App Development チャンネル。

Open your capacitor.config.ts （または capacitor.config.json）ファイル。 " plugins セクション"の下で、オプションでテストビルド defaultChannel （内部 / QA）を設定します。生産ビルドの場合、デフォルトの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 channel

注意

チャンネル選択順序: 強制 > API デバイスオーバーライド > プラグイン setChannel() ローカルチャンネル > 設定 defaultChannel > Cloud Default.

使用 defaultChannel テスト/内部ビルドのみに使用してください。生産用には除外してください。ユーザーはCloud Default (設定済みの場合)に従うのではなく、ネイティブの設定でルーティングを複製するのを避けることができます。

デバイスまたはオーバーライドを強制 (固定) することはまだ可能です。後者はすぐに設定値を上書きします。

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

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

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

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

段階的ロールアウト

を参照してください。 進歩的ロールアウト 配信モデル、ダッシュボードワークフロー、API フィールド、CLI コマンドのための

自動更新戦略の無効化

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

• メジャー: デバイスのネイティブベースラインよりもメジャーバージョンが高いターゲットバンドルのブロック (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.

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

アプリ内で 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()のしくみ (v5.34.0+ / v6.34.0+ / v7.34.0+ / v8.0.0+)

いつ setChannel() 呼ばれる:

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

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

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

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

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

方法	効果時間	保存先	デバイスオーバーライドUIで表示	用途
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 の場合でも同じ機能が含まれます)。 プラグインのインストール を参照してください。

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

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

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

これにより、構築されたWebアセットをアップロードし、チャンネルに新しいバンドルを有効にします。アプリケーションは、更新を検索するたびに、指定されたチャンネルに割り当てられているアプリケーションに更新を提供します。 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.

「バンドルバージョニングとチャンネル」のセクション

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.

__CAPGO_KEEP_0__ セマンティック バージョニングとCapgoのSemver テスター チャンネル固有のビルド用のプレリリース識別子もサポートします。 例えば、ベータ リリースはバージョンとして 1.2.3-beta.1.

CI では、ローカル バージョンが既にアップロードされている場合、 npx @capgo/cli@latest bundle upload --auto-bump (任意の) major, minor, patch/fix, metadata, または ai) により、CLIはチャンネルのリンクされたバンドルからバージョンを上げ、空き名を探すまで続きます。 また、 aiは、ローカルと前のデルタ マニフェストのレベルを推測します (前の__CAPGO_KEEP_0__バージョンがない場合は patch にフォールバックします)。 Capgoのバージョンを組み合わせることはできません。 ご覧ください。 --bundleCI/CD インテグレーション と __CAPGO_KEEP_0__の参照 CLI reference.

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

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

チャンネル:

• Development __CAPGO_KEEP_0__、など 1.2.3-dev.1, 1.2.3-dev.2チャンネル:
• QA __CAPGO_KEEP_0__、など 1.2.3-qa.1, 1.2.3-qa.2protectedTokens
• Staging チャンネル: 1.2.3-rc.1, 1.2.3-rc.2, など
• Production チャンネル: 1.2.3, 1.2.4, など

使用 pre-release識別子を含むsemver は推奨アプローチですが、厳密には必要ではありません。重要なのは、ビルド間の関係を明確に伝え、チームの開発プロセスと一致するバージョニングスキームを見つけることです。

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

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

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

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

自動デプロイ

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

「CI/CD統合」を参照してください CI/CD統合 ライブアップデートの自動化についてもっと学びたい場合は、Capgoのドキュメントをご覧ください。

最小権限のPRプレビュー

ビルドプロセスに統合することで アプリ プレビュー CIでプル リクエストごとに一時的なチャネルを生成する必要があるが、既存のメイン/デフォルト チャネルを管理しないようにするAPIキーは、所有する組織と選択したアプリと結びついています。ただし、組織全体で役割を果たすものではありません。各非公開のプレビュー チャネルは、チャネル スコープのライフサイクル パーミッションを自動的に取得します。

1. 組織管理者がプレビュー アプリに限定されたセキュアなAPI キーを作成し、選択 アプリ プレビュー. ご覧ください API キー.
2. 一意の非公開チャネルを使用します。たとえば pr-123ロールアウト オプション、または --default, --self-assignプル リクエスト バンドルをアップロードしてプロモートし、プル リクエストがクローズしたときに所有するチャネルとバンドルを削除するコマンドを実行できます: --delete-linked-bundle-on-upload.
3. ターミナル ウィンドウ

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つのチャネルを作成し、バンドルをアップロードし、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設定の権限がないからです。GitHub Actionsで、秘密を含むプレビュージョブを実行するには pull_request, ではなく pull_request_target, そして、同じリポジトリのPRに github.event.pull_request.head.repo.full_name == github.repository.

デバイスに展開する

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

1. アプリにCapgo SDKをインストールします
2. アプリを自分の望ましいチャネルにリスニングするように設定します
3. アップロードしたビルドをそのチャンネルに割り当てます。
4. アプリを起動し、更新を待ちます!

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

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

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

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

Capgoのガイドを参照して、以下の高度な用途を実装する方法を学びましょう: 機能フラグとA/Bテストのためにユーザーをプランとチャンネルで分割する方法.

チャンネルから続けて

Capgoのチャンネル機能を使用している場合 チャンネル チャンネル機能を使用して、プランチャンネルルーティングとステージドロールアウトを計画し、接続する チャンネル チャンネル機能の実装詳細については、チャンネルを参照してください チャンネル チャンネル機能の実装詳細については、チャンネルを参照してください ベータテストソリューション 製品ワークフローBetaテストソリューション用 バージョン目標ソリューション 製品ワークフローVersion Targeting Solution用 Capgo環境ベストプラクティス：1つのモバイルアプリIDでステージング Capgo環境ベストプラクティス：1つのモバイルアプリIDでステージングの実用的な文脈