チャンネル

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

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

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

デバイスがアップデートをチェックするとき、Capgo は、次の順序 (優先順位が高い順) でチャンネルを選択する:

強制的なデバイスマッピング (ダッシュボード) – 特定のデバイス ID をチャンネルに固定する。緊急のデバッグまたは制御テストに使用する。常に勝つ。Capgo は、最後のオーバーライドの書き込みから 90 日後にマッピングを削除する。詳細はこちら。コンソールと API のオーバーライドは 90 日後に期限切れになる.
Cloud オーバーライド (デバイスごと) via ダッシュボードまたは API – ダッシュボードまたは API でデバイスのチャンネルを変更したときに作成される。QA ユーザーが機能 / PR チャンネル間で切り替えるか、ユーザーイシューを再現するために使用する。バイナリを再インストールしても削除されないが、デバイスオーバーライドを削除すると削除される。同様に、90 日の保持期間が適用される。
プラグイン setChannel() ローカルチャネル – アプリが呼び出したときに作成される setChannel() バックエンドがターゲットチャネルが自己割り当てを許可しているかを検証し、選択したチャネルはそのデバイス上でローカルに保存され、即効果を発揮し、デバイスオーバーライドUIには表示されない。

プラグインバージョン 5.34.0、6.34.0、7.34.0、または 8.0.0 (メジャーバージョンに応じて) から (依存するメジャーバージョンに応じて) setChannel() バックエンドに接続して 有効かどうかを検証する チャネルが許可されているかどうかを検証し、チャネルはデバイス上でローカルに保存される setChannel()を使用した即時チャネル切り替え の defaultChannel。新しいチャンネルが有効になるのは の更新チェックの次の時点で— の待たずに。

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

のデータベース (例: または__CAPGO_KEEP_0__の変更) に、デバイスは2分以内にデータの再同期を待たなければならなかった。新しい動作は、バックエンドからのみ読み取り (検証用) して、ローカルに保存するため、チャンネル切り替えは即座に実行される。 setChannel() の はローカルのみなので、 はCapgoのダッシュボードにデバイスオーバーライドエントリを作成しない。デバイスオーバーライドUIは、ダッシュボードまたはパブリックAPIからのみオーバーライドを作成したものを表示する。

のがローカルに設定された後でも、チャンネルが許可されなくなった場合でも、バックエンドは更新チェック中にチャンネルを検証するため、セキュリティは維持される。

重要な注意事項: ダッシュボードまたはAPIを通じてチャンネルが変更された場合、エッジサーバー全体が変更を反映するまで2分以内に遅延が発生します。即時チャンネル切り替えには setChannel() アプリケーションからcodeを使用してください。バックエンドと検証し、ローカルにチャンネルを設定して即時効果を得ます。

Capacitor設定 defaultChannel (テストビルドのデフォルト) – __CAPGO_KEEP_0__に存在し、強制/オーバーライド/ローカルチャンネルが存在しない場合、Appはこのチャンネルから起動します (例えば) capacitor.config.* . この設定は、テストフライト/内部ビルド用にテストラーが自動的にプレリリースチャンネルに到達するように設計されています。通常、プロダクションビルドではこの設定を空にします。 beta, qa, pr-123クラウドのデフォルトチャンネル (主なパス ~99% のユーザー)
– ダッシュボードでデフォルトチャンネルをマークした場合、すべての通常のエンドユーザー (強制、ダッシュボード/__CAPGO_KEEP_0__オーバーライド、プラグインローカルチャンネル、設定のdefaultChannelが存在しない場合) はここに接続します。変更をロールアウトまたはロールバックすると、新しいバイナリなしで即座に実行できます。プラットフォーム固有のデフォルト (例えば、iOSのみ、Androidのみ、Electronのみ) を設定した場合、各デバイスは対応するプラットフォームにマッチするデフォルトに接続します。クラウドのデフォルトを空にした場合、デバイスはステップ1–4にマッチする場合にのみ更新を受け取ります。 – If you mark a default channel in the dashboard, all normal end‑users (no force, no Dashboard/API override, no plugin local channel, no config defaultChannel) attach here. Change it to roll out or roll back instantly—no new binary. If you have platform-specific defaults (for example, one iOS-only, one Android-only, one Electron-only), each device lands on the default matching its platform. Leaving the cloud default unset is allowed; in that case the device must match on steps 1–4 to receive updates.

ステップ1–4を除外/テストレイヤーとして扱い、クラウドのデフォルトを設定した場合、実ユーザーはそこに流れ込むようにしてください。クラウドのデフォルトを設定しない場合は、ユーザーがどのように接続するか (通常は)

を使用してください。 defaultChannel configまたはデバイスごとのオーバーライドで設定します。
Only configure defaultChannel テスターに明示的に配布するバイナリのみで設定します。設定しないと、生産環境のロジックはダッシュボードに集中されます。
Use setChannel() 生産環境ではsparinglyで使用し、主にQAまたはターゲットされた診断に使用します。

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

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

コンソールとAPIオーバーライドは90日後に期限切れになります。

強制マッピングとダッシュボードまたはパブリックAPIチャンネルオーバーライドはCapgoでデバイスごとに割り当てられます。クリーンアップジョブは割り当てを削除します。 90 日間の最後のオーバーライド書き込み後更新を確認することは、その時計をリセットしない。

オーバーライドを書き込む (または自分で削除する) ことでタイムスタンプが変更される。これは. Inventory removes devices that have not connected to Capgo for 90 days. Override cleanup removes the mapping even if the device is still active.

とは異なる。

インベントリは、90 日間接続していないデバイスを削除する。オーバーライドのクリーンアップは、デバイスがまだアクティブな場合でもマッピングを削除する。 defaultChannel このクリーンアップによって削除されない割り当ての場合: capacitor.config.* セット
イン setChannel() （再インストールしても存続する; 後で変更するには新しいネイティブバイナリが必要)。 setChannel() アプリから呼び出す。プラグイン 5.34.0 / 6.34.0 / 7.34.0 / 8.0.0 以降、割り当てはローカルであり、このクリーンアップによって削除されない。アプリを再インストールすると、クリアされるため、アプリは再び呼び出す必要がある。

チャンネル デバイス タブとデバイスのオーバーライドUIは、コンソールとパブリックAPI割り当てのみを表示します。デバイスのリストはすべて表示されず、ローカル setChannel() 割り当ても表示されません。

Capgoチャンネルデバイスタブに表示されるオーバーライドの保持ポップオーバー:コンソールオーバーライドは90日後に期限切れ — チャンネルデバイスタブに表示されるオーバーライドの保持の注意

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

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

– iOS、Android、Electronが有効になっているチャンネルが1つだけのデフォルトになり、オーバーライドがなければデバイスはここにアタッチされます。 シングルデフォルト（最も一般的な）
プラットフォーム固有のデフォルト – プラットフォームごとにチャンネルを分割する場合 (例えば、iOSのみ有効、Androidのみ有効、Electronのみ有効)、各プラットフォームごとにデフォルトをマークします。 iOSデバイスはiOSデフォルトに、AndroidデバイスはAndroidデフォルトに、ElectronアプリはElectronデフォルトにアクセスします。 ios-production iOSデバイスはiOSデフォルトに、AndroidデバイスはAndroidデフォルトに、ElectronアプリはElectronデフォルトにアクセスします。 android-production クラウドデフォルトと両方が同じ決定レイヤーを占めます。クラウドデフォルトを設定すると、__CAPGO_KEEP_0__ 設定に値を複製する必要がなくなります—生産用ビルドの場合、空白のままにします。テスターまたはQAに非生産用チャンネルを送信したい場合は、クラウドデフォルトと異なる値を使用する必要があります。 electron-production デフォルト値を変更するには、ダッシュボードでいつでも行うことができます。チャンネルを開き、Manage in App設定をクリックしてください

Manage in App設定 defaultChannel 生産用ビルド 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 QA defaultChannel 非生産用チャンネル

生産用ビルド テスター、をクリックするとアプリ情報。デフォルトはチャンネルページで切り替えられなくなりました。デフォルトを入れ替えると、新しいデバイスは即座に新しいルーティングに従い、既存のデバイスは次回チェックインするときに通常の優先順位ルールに従います。

チャンネルの設定

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

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

チャンネル名はあなたが好きなように自由に設定できます。一般的な戦略は、開発段階にチャンネルをマッチさせることです。

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

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

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

ファイルを開きます。 capacitor.config.ts (または capacitor.config.json)ファイル。 “チャンネル”セクションの下で、オプションで “テストビルド” を設定します。 plugins チャンネル defaultChannel test builds test builds (内部 / 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 プロジェクトにコピーします。構成の同期をスキップすると、以前の設定に従って、ネイティブプロジェクトが使用するチャンネルが継続します。

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

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

デフォルトチャンネル: 新しいデバイスが接続したときに、チャンネルまたはプラットフォーム固有のチャンネルをオプションで指定できます。コンソールでは、App Information(アプリ設定を管理 チャンネルページから)にあります。詳細は「デフォルトチャンネル動作」で確認してください。
プラットフォームフィルタ: チャンネルごとに、__CAPGO_KEEP_0__、または__CAPGO_KEEP_1__に配信するデバイスを有効または無効にできます。 iOS, Android自動ダウングレードを無効にする: デバイスのネイティブアプリのバージョンがチャンネルのバンドルよりも新しい場合に、更新を送信しないようにします (例: デバイスが1.2.3のバージョンで、チャンネルが1.2.2のバンドルを持っている場合)。 Electron 開発用ビルドを許可する: 開発用ビルドに更新を許可します (テストに便利です)。__CAPGO_KEEP_0__:
__CAPGO_KEEP_1__
CLI --dev / --no-dev.
生産ビルドの許可: 生産 (ストア) ビルドへの更新を許可します。実際のユーザーにサービスを提供するチャンネルでは、この設定をオンにします。 CLI: --prod / --no-prod.
エミュレータデバイスの許可: エミュレータ/シミュレータ (テストに役立つ) への更新を許可します。 CLI: --emulator / --no-emulator.
物理デバイスの許可: 実際のスマートフォンやタブレットへの更新を許可します。生産チャンネルでは、この設定をオンにします。 CLI: --device / --no-device.
デバイスの自己割り当ての許可: アプリが実行時、このチャンネルに切り替えることができるようにします。 setChannel . として指定します。この設定を無効にすると、 setChannel will fail for this channel. CLI: --self-assign / --no-self-assign.
パッケージの更新: デバイスが、完全な ZIP、変更されたファイルの delta、または両方 (all, zip, delta, zip_from_builtin, delta_from_builtinをダウンロードするかどうかを選択します。ご参考までに、パッケージの更新を参照してください。また、コンソールのドロップダウンと各モードの使用時期についても説明しています。

段階的なロールアウト

A channel can maintain a stable bundle while gradually exposing a separate rollout target to a sticky device cohort. You can pause, resume, promote, roll back, and configure an automatic failure response without switching the channel for everyone. See Progressive rollouts for the delivery model, dashboard workflow, API fields, and CLI commands.

Auto Update strategy の無効化

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

major: デバイスのネイティブベースラインよりも高いメジャーバージョンのターゲットバンドルをブロックします (version_build例えば: 1.2.3 -> 2.0.0 許可されます。 1.2.3 -> 1.9.0 ブロックされます。
minor: メジャーまたはマイナーバージョンが異なるターゲットバンドルをブロックします。 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設定されていない場合、チャネルは不正設定とみなされ、更新は拒否されます。
semver互換性に従ってすべての更新を許可します。 semver compatibility.

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

詳細と例については、/docs/cli/commands/#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() を使用してアプリから

このメソッドは、アプリが実行時でチャンネルを切り替えることを可能にします。これは、特に以下のシナリオで便利です。 setChannel() QA/デバッグメニューでテスターがチャンネルを切り替えることができる場合

QA/debug menus where testers can switch between channels
ベータプログラムのオプティンフロー
機能フラグの実装
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の変更も)。デバイスは、最大2分間バックエンドのリプリカシオンの待機をしながら、チャネル変更の効果が生じました。現在、 setChannel() バックエンドからのみ読み取り (検証用) して、ローカルに保存するため、チャネル切り替えは即時になりました。

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

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

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

方法	効果時間	永続保存場所	デバイスオーバーライドUIで表示	有効期限	使用例
`setChannel()` プラグインから	即時	デバイスのみ(ローカル)	なし	変更または再インストールするまで	アプリ内でユーザーがチャンネルを切り替える
デバイスオーバーライドダッシュボード	最大 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 の場合)。プラグインのインストールバージョンタグについて

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

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

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

このアクションは、ビルドされたウェブアセットをアップロードし、チャンネルに割り当てられた新しいバンドルを有効にします。 Development チャンネル。そのチャンネルに接続してあるアプリは、次に更新をチェックするときにその更新を受け取る。

また、 “バンドル” セクションの Capgo ダッシュボードから、ビルドをチャンネルに割り当てることもできます。ビルドの隣にあるメニューアイコンをクリックし、「チャンネルに割り当てる」を選択して、そのビルドのチャンネルを選択してください。

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

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

バンドルをバージョン化する際には、セマンティックバージョニングを使用し、Capgo の Semver テスターとともに、チャンネル固有のビルド用にプレリリース識別子を使用することをお勧めします。たとえば、ベータリリースはバージョンとして 1.2.3-beta.1.

CI で、ローカルバージョンがすでにアップロードされていた場合、 npx @capgo/cli@latest bundle upload --auto-bump （任意の） major, minor, patch/fix, metadata）を使用して、__CAPGO_KEEP_0__ がチャンネルのリンクされたバンドルからバージョンを上げるのを続け、空の名前が見つかるまでにします。 ai) so the CLI bumps from the channel’s linked bundle until a free name is found. With ai、Workers AIは、ローカルvs前回のdeltaマニフェストからインファーするレベル (前回のマニフェストがない場合は)、 patch with no previous Capgo version). You cannot combine it with --bundleとを参照してください。 CI/CD統合 CLI reference.

と

__CAPGO_KEEP_0__ リファレンス 1.2.3-beta.1 このアプローチにはいくつかの利点があります。 1.2.3.
ビルド間の関係を明確に伝えることができます。
明らかに__CAPGO_KEEP_0__は 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をビルドプロセスに統合すると、新しいバンドルを自動的にアップロードし、特定のブランチにプッシュしたり、新しいリリースを作成したりするたびにチャンネルに割り当てることができます。

チェックアウト CI/CD統合 Capgoの自動化についてさらに学びましょう。

最小権限のPRプレビュー

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

組織管理者がプレビュー用に制限されたAPI キーを作成し、選択 アプリプレビューを参照してください。 API キー.
独自の非公開チャンネルを使用してください pr-123パブリックチャンネルを使用しないでください --default, --self-assignロールアウトオプションを渡さないでください --delete-linked-bundle-on-upload.
PRバンドルをアップロードしてプロモートするコマンドを1つにし、PRがクローズされたときに所有するチャンネルとバンドルを削除してください

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 ターミナルウィンドウ

If reviewers need a QR code or preview URL, an administrator must enable previews once for the app:

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

An App Preview key cannot enable previews itself because it has no app-settings permission. In GitHub Actions, run secret-bearing preview jobs on pull_requestApp Preview キーはアプリ設定の権限がないため、プレビュージョブを実行することはできません。__CAPGO_KEEP_0__ Actions で、シークレットを含むプレビュージョブを実行するには pull_request_target, それらの制限を同じリポジトリのPRに github.event.pull_request.head.repo.full_name == github.repository.

デバイスへの展開

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

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

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

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

チャネルは開発段階のみに使用されるものではありません。ユーザー分割の強力なツールであり、機能の実装に役立ちます。

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

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

チャネルから続けて

チャネルコンテキスト:Capgoリリースチャネル機能名。ページ/エリア:Capgoソリューションマーケティングページ。役割:短いUIラベルまたはナビゲーションアイテム。チャンネルルーティングとステージドロールアウトの計画に役立つ機能です。チャンネルチャンネルチャンネルベータテストソリューションベータテストソリューションの製品ワークフローバージョン対象ソリューションバージョン対象ソリューションの製品ワークフロー環境ベストプラクティス: ステージングと1つのモバイルアプリID Capgo Environment Best Practices: Staging with One Mobile App ID for the practical context in Capgo Environment Best Practices: Staging with One Mobile App ID.