コンテンツに進む
Capgo - Capacitor Live Updates Capgo

チャンネル

A Live Update チャンネルは、特定のアプリのJSバンドルビルドへの参照を持ち、指定されたチャンネルに接続しているデバイスにアップデートを共有します。チャンネルへの参照を変更したり、必要に応じて前のバージョンに戻したりすることができます。 install the Capgo Live Updates SDK チャンネルは機密性を提供しません。

強制的なデバイスマッピング (ダッシュボード)

__CAPGO_KEEP_0__

デバイスがアップデートを確認するとき、Capgoは次の順序（優先度が高い順）で使用するチャンネルを決定します。

  1. __CAPGO_KEEP_0__ – 1台のデバイスIDを特定のチャネルに固定します。緊急デバッグや制御されたテストに使用します。1つだけの実ユーザーとテストします。この設定は常に優先されます。 Capgo は、最後のoverride書き込み後90日間でマッピングを削除します。詳しくは コンソールと API のoverrideは90日後に期限切れになります.
  2. Cloud override (per-device) via ダッシュボードまたは API – デバイスのチャネルをダッシュボードまたは API で変更したときに作成されます。QAユーザーが機能/PRチャネル間で切り替えたいときやユーザー問題を再現したいときに使用します。バイナリを再インストールしても削除されません。デバイスのoverrideを削除しても削除されません。同様に90日間の保持期間が適用されます。
  3. プラグイン setChannel() ローカルチャネル – アプリが呼び出しを行い、バックエンドがターゲットチャネルが自己割り当てを許可していることを検証したときに作成されます。選択したチャネルはデバイス上でローカルに保存され、即座に効果を発揮し、デバイスオーバーライドUIに表示されません。 setChannel() setChannel()を使用した即時チャネル切り替え
  1. Capacitor設定 defaultChannel (テストビルドのデフォルト) – __CAPGO_KEEP_0__に存在し、強制/オーバーライド/ローカルチャンネルが存在しない場合、Appはこのチャンネルから起動します (例えば capacitor.config.* テストフライト/内部ビルド用に設計されています。テスト者が自動的にプレリリースチャンネルにアクセスするようにします。生産ビルドは通常、この値を未設定のままにします。 beta, qa, pr-123テストフライト/内部ビルド用に設計されており、テスターは自動的にプレリリースチャンネルに到達します。通常、プロダクションビルドではこの値を設定しません。
  2. クラウドデフォルトチャネル（主なパス~99％のユーザー） – ダッシュボードでデフォルトチャネルをマークすると、すべての通常のエンドユーザー（強制なし、ダッシュボード/APIオーバーライドなし、プラグインローカルチャネルなし、config defaultChannelなし）がここにアタッチされます。デフォルトを変更すると、即座にロールアウトまたはロールバックできます—新しいバイナリなし。プラットフォーム固有のデフォルト (例：iOSのみ、Androidのみ、Electronのみ) を持っている場合、各デバイスはそのプラットフォームに合ったデフォルトにアタッチされます。クラウドデフォルトを未設定にすると許可されます。そうすると、デバイスはステップ1–4にマッチする場合にのみアップデートを受け取ります。

ベストプラクティス:

  • 1–4を例外/テストレイヤーとして扱い、クラウドデフォルトを設定した場合、実際のユーザーはそこに流れ込むようにします。デフォルトを設定しない場合は、ユーザーがアタッチする方法については、意図的に考慮する必要があります (通常はconfigまたはデバイスごとのオーバーライドを使用します)。 defaultChannel Only configure
  • クラウドデフォルトを defaultChannel クラウドデフォルトを
  • クラウドデフォルトを setChannel() クラウドデフォルトを

クラウドデフォルトを

概要: 強制 > ダッシュボード/API オーバーライド > プラグイン setChannel() クラウドデフォルトを defaultChannel > Cloud Default.

コンソールとAPIのオーバーライドは90日間有効です。

「コンソールとAPIのオーバーライドは90日間有効です」

強制マッピングとダッシュボードまたはパブリックAPIチャンネルオーバーライドは、Capgoにデバイスごとに割り当てられます。クリーンアップジョブは、その割り当てを削除します。 90日以内に最後のオーバーライド書き込み後.更新をチェックすることはその時計をリセットしません。オーバーライドを書き込む (または自分で削除する) ことでタイムスタンプが変更されます。

Capgo デバイスインベントリの保持。インベントリは、Capgoに接続していないデバイスを90日以内に削除します。オーバーライドクリーンアップは、デバイスがまだアクティブな場合でもマッピングを削除します。

この割り当てがクリーンアップによって削除されない場合:

  • Set defaultChannel in capacitor.config.* (再インストールしても存続する; 以降の変更には新しいネイティブバイナリが必要)
  • Call setChannel() アプリから setChannel() 再インストールすると消去されるため、アプリが再度呼び出す必要がある

チャンネル デバイス デバイスタブとデバイスオーバーライドUIのみコンソールとPublicAPI割り当てを表示します。すべてのデバイスを表示せず、ローカル割り当ても表示しません。 setChannel() assignments.

デバイスオーバーライドUIのみコンソールとPublicCapgo割り当てを表示します。すべてのデバイスを表示せず、ローカル割り当ても表示しません。
チャンネルデバイスタブで保持期間の通知をオーバーライド。

デバイスオーバーライドUIのみコンソールとPublic__CAPGO_KEEP_0__割り当てを表示します。すべてのデバイスを表示せず、ローカル割り当ても表示しません。

Default Channel Behavior

クラウドのデフォルトを設定することは任意ですが、通常は新しいデバイスのキャッチオールパスとして機能します。デフォルトがなければ、強制マッピング、オーバーライド、または defaultChannel Capacitor 設定内では、更新を受け取ります。デフォルトを選択する際には、次のパターンを考慮してください。

  • 単一のデフォルト（最も一般的なケース） – iOS、Android、および Electron が有効になっているチャンネルが 1 つだけの場合、デフォルトになります。オーバーライドがなければ、デバイスはここにアタッチされます。
  • プラットフォーム固有のデフォルト – プラットフォームごとにチャンネルを分割する場合、 （例えば） ios-production クラウドのデフォルトと android-production クラウドのデフォルトと electron-production 両方が同じ決定層を占めます。クラウドのデフォルトを設定した場合、__CAPGO_KEEP_0__ の設定に値を複製する必要はありません—値を

単一のデフォルト（最も一般的なケース） defaultChannel in capacitor.config.* 両方が同じ決定層を占めます。クラウドのデフォルトを設定すると、Capacitor の設定ファイルに値を複製する必要がなくなるため、値をそのまま残しておくことができます。 defaultChannel 生産用ビルドの場合、空のままにしておきます。テスターまたはQAに送信するバイナリを予約します。 defaultChannel 非生産チャンネルでテスターまたはQAに送信したい場合に、クラウドのデフォルトが異なる場合でも、テスターまたはQAに送信したバイナリを開始させたいときに予約します。

デフォルトを変更することがいつでもダッシュボードで可能です。チャンネルを開き、次に「アプリ設定の管理」を開きます。 これにより、チャンネルページにデフォルトが表示されなくなりました。デフォルトを入れ替える際に、新しいデバイスは即座に新しいルーティングに従い、既存のデバイスは次回チェックインするときに通常の優先順位ルールに従います。チャンネルの設定 チャンネルの設定初期設定の際に最初のチャンネルを作成します（チームはほとんどが「生産」に名付けます）。しかし、ロックはありません。チャンネル名を変更したり削除したりすることがいつでもできます。追加のチャンネルを追加するには:

「チャンネル」セクションの__CAPGO_KEEP_0__ダッシュボードに移動します。

「新しいチャンネル」ボタンをクリックします。

チャンネルの設定

  1. Go to the “Channels” section of the Capgo dashboard
  2. 「チャンネル」セクションの__CAPGO_KEEP_0__ダッシュボードに移動します。
  3. チャンネル名を入力して「作成」をクリックしてください。

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

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

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

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

アプリを開いてください。 Development (または

context capacitor.config.ts (or capacitor.config.json)ファイル。下の plugins セクションに、オプションで defaultChannel テストビルド の 設定

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アプリをビルドし、

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

Channel Options and Strategies

Channels have several options that control who can receive updates and how updates are delivered. The most important ones are below. You can configure these from the web app, the CLI, or the Public API.

  • プラットフォームフィルタ: 配信を有効または無効にします。プラットフォームフィルタ: 配信を有効または無効にします。 Platform filters: Enable or disable delivery to
  • Platform filters: または配信を有効/無効にします iOS, Android、または Electron チャンネルごとに
  • native の下で自動ダウングレードを無効にする: デバイスのネイティブアプリのバージョンがチャンネルのバンドルよりも新しい場合 (例: デバイスが 1.2.3 である場合、チャンネルが 1.2.2 を持っている場合)、アップデートを送信しないようにする。
  • 開発用ビルドを許可する: テストに役立つため、開発用ビルドへのアップデートを許可する。 CLI: --dev / --no-dev.
  • 生産用ビルドを許可する: 実際のユーザーが利用するチャンネルの場合、ストアのビルドへのアップデートを許可する。 CLI: --prod / --no-prod.
  • エミュレータ用デバイスを許可する: テストに役立つため、エミュレータ/シミュレータへのアップデートを許可する。 CLI: --emulator / --no-emulator.
  • 実機デバイスを許可する: 実機のスマートフォンやタブレットへのアップデートを許可する。生産用チャンネルの場合にオンにしたままにしておく。 CLI: --device / --no-device.
  • デバイスの自己割り当てを許可する: このチャンネルにアプリが実行中のときにアプリがこのチャンネルに切り替えることができるようにする。 __CAPGO_KEEP_0__: setChannel、を使用します。無効の場合、 setChannel このチャンネルでは失敗します。 CLI: --self-assign / --no-self-assign.
  • ダウンロード形式: デバイスがフルZIP、変更されたデルタファイルのみ、または両方の「」のうちのどちらかをダウンロードするかを選択します。詳細は「all, zip, delta, zip_from_builtin, delta_from_builtin] ダウンロード形式 コンソールのドロップダウンと各モードの使用方法。

進化的なロールアウト

Progressive rollouts

進化的なロールアウト 進化的なロールアウト for the delivery model, dashboard workflow, API fields, and CLI commands.

ダウンロード形式

自動更新戦略の無効化

自動更新戦略の無効化

  • 自動更新戦略の無効化version_build). Example: 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 は許可されます。
  • patch: 最も厳密なモードです。メジャー、ミニマム、パッチ番号の変更は許可されず、サフィックスの変更のみ許可されます。 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: 各パッケージに最低限のアップデートバージョンメタデータが必要です。CLIを使用して設定します。 --min-update-version または、 --auto-min-update-version設定されていない場合は、チャネルが不正設定と見なされ、更新が拒否されます。
  • none: すべての更新を許可します。 semver互換性.

これらの戦略では、チャネルのターゲットバンドルが送信されたネイティブベースラインと比較されます。 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()を使用するアプリ

Section titled “アプリ内で setChannel() を使用する方法”

The setChannel() methodは、実行時アプリがプログラムでチャンネルを切り替えることを可能にします。この機能は、以下のような場合に特に便利です。

  • テスト者がチャンネルを切り替えるための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
});

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

Channel への Bundle の割り当て

To deploy a live update, you need to upload a new JS bundle build and assign it to a channel. You can do this in one step with the Capgo CLI:

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

GitHub Development Capgo

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.

API

SDK

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.

npm semantic versioning with CapgoのSemver テスター Live Updateのチャンネル固有のビルド用のバージョン番号と、プレリリース識別子です。例えば、ベータ版リリースはチャンネル固有のビルド用のバージョン番号として} 1.2.3-beta.1.

CI で、ローカル版がすでにアップロードされていた場合に使用します。 npx @capgo/cli@latest bundle upload --auto-bump (選択的に) major, minor, patch/fix, metadata、または ai) そのCLIはチャンネルにリンクされているバンドルのバージョンから、空き名が見つかるまでバウンスします。 ai,ワーカー AI はローカル vs 前回のデルタマニフェストから推測します (前回のマニフェストにフォールバックします) patch with no previous Capgo version). You cannot combine it with --bundle. CI/CD統合 とともに CLI リファレンス.

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

  • ビルド間の関係を明確に伝える。 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 with pre-release identifiers __CAPGO_KEEP_0__ をロールバックする

セクションのタイトル “Live Update をロールバックする”

ロールバックのLive Update

If you deploy a live update that introduces a bug or otherwise needs to be reverted, you can easily roll back to a previous build. From the “Channels” section of the dashboard:

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

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

自動デプロイ

「自動デプロイ」のセクション

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

CI/CD統合 CI/CD統合 docs to learn more about automating Capgo live updates.

CI/CD統合

CI/CD統合

CI/CD統合 CI/CD統合 API key when CI needs one temporary channel per pull request but must not manage existing main/default channels. The key remains bound to the owning organization and selected app; it simply has no organization-wide role. Each non-public preview channel it creates receives its own automatic, channel-scoped lifecycle permission.

  1. 組織管理者がプレビュー用に制限された API キーを作成し、選択 アプリプレビュー. See API キー.
  2. ユニークで非公開のチャンネルを使用します。 pr-123ロールアウトオプションや --default, --self-assignPR バンドルをアップロードしてプロモートし、PR がクローズした後、チャンネルとバンドルを削除します: --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 レビューアがQR __CAPGO_KEEP_0__ またはプレビュー URLが必要な場合、管理者はアプリに対してプレビューを有効にする必要があります:

レビュアーが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 キーは、自身のアプリ設定権限がないため、プレビューを有効にすることはできません。GitHub アクションで、シークレットを含むプレビュー ジョブを実行するには pull_request, ではなく pull_request_target, および、同じリポジトリの PR に制限する github.event.pull_request.head.repo.full_name == github.repository.

デバイスにデプロイ

「デバイスにデプロイ」セクション

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

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

詳細なチュートリアルについては、 ライブアップデートの 展開

を参照してください。

ライブアップデートの

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

  • セクション
  • A/B テスト
  • チャネルは、開発段階のみに使用するのではなく、より多くの用途に使用できます。ユーザー分割の強力なツールであり、以下のような機能を実現できます。
  • ユーザー層ごとの機能フラグ

A/B テスト 機能の段階的なロールアウト.

チャンネルから続きます

チャンネルから続きます

チャンネルを使用している場合 チャンネル チャンネル チャンネル チャンネル チャンネル チャンネル ベータテストソリューション ベータテストソリューション バージョン目標ソリューション バージョン目標解決の製品ワークフローについて Capgo 環境のベストプラクティス: ステージングに1つのモバイルアプリID 実践的なCapgo 環境のベストプラクティス: ステージングに1つのモバイルアプリID