チャネル

Live Updateチャンネルは、任意のデバイスがそのチャンネルに接続して更新を待っている場合に、特定のJSバンドルビルドのアプリケーションを指します。Live Updatesを install the Capgo Live Updates SDK __CAPGO_KEEP_1__

チャンネルは機密性を提供しない

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_KEEP_0__にアップロードされた未暗号化のバンドルは、依然としてクライアントに配信されるパブリックアセットとして扱うべきである。エンクリプションは配信パスの保護と更新の有効性を保証するが、配布されたアプリケーションを十分な努力で逆アセンブルすることで、配布されたアプリケーションからバンドルを逆アセンブルすることができる。詳しくは「Live Update encryption」を参照してください。 for details.

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

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

1. デバイスの強制マッピング（ダッシュボード） – 急いでデバッグするか、制御されたテストを行うために、特定のデバイスIDをチャンネルに固定します。
2. Cloud override (per‑device) via Dashboard or API Cloud override (per‑device) via Dashboard or API
3. – ダッシュボードまたは__CAPGO_KEEP_0__でデバイスのチャンネルを変更すると作成されます。QAユーザーが機能/PRチャンネル間で切り替えたい場合やユーザー問題を再現したい場合に使用します。再インストールするとこの設定はクリアされません。 setChannel() Capacitor Plugin setChannel() local channel、– アプリが呼び出し、バックエンドがターゲットチャンネルが自己割り当てを許可していることを検証した場合に作成されます。選択されたチャンネルは、デバイス上でローカルに保存され、即座に効果を発揮し、デバイスオーバーライド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__からアプリケーションを使用してください。—バックエンドと検証し、ローカルにチャンネルを設定して即効性を実現します。

__CAPGO_KEEP_0__設定 When channel changes are made via the Dashboard or API, there is still a replication lag of up to 2 minutes before all edge servers reflect the change. For instant channel switching, use setChannel() code設定

4. Capacitor設定 defaultChannel (test build default) – これが存在する場合、 capacitor.config.* と強制/オーバーライド/ローカルチャネルが存在しない場合、このチャネルでアプリが起動します (例: ). beta, qa, pr-123テストフライト / 内部ビルド用に設計されています。テスト者は自動的にプレリリースチャネルに到達します。生産ビルドは通常、この値を未設定にします。
5. Cloud Default Channel (主なパス ~99% のユーザー) – ダッシュボードでデフォルトチャネルをマークすると、すべての通常のエンドユーザー (強制なし、ダッシュボード/API オーバーライドなし、プラグインローカルチャネルなし、config defaultChannel なし) ここに接続します。変更すると即座にロールアウトまたはロールバックできます。新しいバイナリなし。プラットフォーム固有のデフォルト (例: iOS-only、Android-only、Electron-only) を持っている場合、各デバイスは対応するプラットフォームのデフォルトに接続します。Cloud Default を未設定にすると、デバイスはステップ 1–4 に一致する場合にのみ更新を受け取ります。

ベストプラクティス:

• 1–4 を例外 / テスト層と扱いましょう。Cloud Default を設定すると、実ユーザーはそれに流れ込むはずです。Cloud Default を設定しない場合は、ユーザーがどのように接続するか (通常は config またはデバイスごとにオーバーライド) に意識してください。 defaultChannel Only configure
• テスト用に明示的に配布するバイナリのみで設定します。Cloud Default を未設定にすると、生産ロジックはダッシュボードに集中します。 defaultChannel Use
• – setChannel() 稼働中ではあまり使用されませんが、QAや特定の診断用途で主に使用されます。

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

概要： 強制 > ダッシュボード/API オーバーライド > プラグイン setChannel() ローカルチャネル > 設定 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:

• – iOS、Android、および Electron が有効になっているチャネルが 1 つだけの場合、デフォルトになります。オーバーライドなしのデバイスはすべてこのデフォルトにアタッチされます。 プラットフォーム固有のデフォルト
• __CAPGO_KEEP_0__ – プラットフォームごとにチャンネルを分割する場合 (例えば、 ios-production iOSのみ有効にした場合、 android-production Androidのみ有効にした場合、 electron-production Electronのみ有効にした場合)、それぞれのプラットフォームのデフォルトとしてそれぞれをマークします。 iOSデバイスはiOSのデフォルトに、AndroidデバイスはAndroidのデフォルトに、ElectronアプリはElectronのデフォルトにアクセスします。

Cloudflareのデフォルトと defaultChannel in capacitor.config.* 両方は同じ決定レイヤーを占有します。Cloudflareのデフォルトを設定した場合、Capacitorの構成に値を複製する必要はありません—生産ビルドの場合、空白のままにし、 defaultChannel テストやQAに意図的にビンナリを配布したい場合は、Cloudflareのデフォルトと異なるチャンネルにアクセスするようにします。 defaultChannel デフォルトを変更することはいつでもダッシュボードで行うことができます。デフォルトを入れ替えると、新しいデバイスは新しいルーティングに即座に従い、既存のデバイスは次回チェックインするときに通常の優先順位ルールに従います。

チャンネルの設定

セクションのタイトルは “チャンネルの設定”です。

オンボード中に最初のチャネルを作成します（多くのチームは「Production」と呼びますが）、しかし、ロックはありません—あなたはいつでもチャネル名を変更したり削除したりできます。追加のチャネルを追加するには：

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

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

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

チャネルをアプリに設定する

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

Open your capacitor.config.ts (または capacitor.config.json)ファイル。チャンネルセクションの下で、オプションで plugins テストビルド defaultChannel の場合、内部(QA) / QAの場合。生産ビルドの場合、デバイスがCloud Defaultを使用するようにするには、明示的にオーバーライドする必要があります。 クリップボードにコピー 次に、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 __CAPGO_KEEP_0__

注意

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

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

デバイスを強制（固定）したりオーバーライドを適用したりすることはまだできます。それらは、config値を上書きします。

チャネル名は大文字小文字区別です。

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

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

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

段階的ロールアウト

チャネルは安定したバンドルを維持しながら、固有のデバイスコホートに別のロールアウトターゲットを段階的に公開できます。ロールアウトを一時停止、再開、昇格、ロールバック、自動失敗応答の自動設定を行うことができます。ただし、すべてのユーザーにチャネルを切り替える必要はありません。 進歩的なロールアウト APIのための配信モデル、ダッシュボードワークフロー、CLIコマンドのための

Auto Update戦略の無効

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

• メジャー：デバイスのネイティブベースラインよりもメジャーバージョンが高いターゲットパッケージをブロックします（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 は許可されます。
• 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互換性に従ってすべての更新を許可します。.

の戦略は、チャネルのターゲットバンドルを、native基準として送信されたnative基準と比較します。 version_build, not the current downloaded bundle sent as version_name.

Learn more details and examples in Disable updates strategy at /docs/cli/commands/#disable-updates-strategy.

Example (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

CapgoアプリからsetChannel()を使用する

The setChannel() setChannel()メソッドは、実行時アプリがプログラム的にチャンネルを切り替えることを可能にします。この機能は、以下のシナリオで特に便利です。

• QA/デバッグメニューでテスターがチャンネルを切り替える
• ベータプログラムへの参加フロー
• 機能フラグの実装
• A/B testing scenarios

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

v5.34.0+ / v6.34.0+ / v7.34.0+ / v8.0.0+ の setChannel() の動作

いつ setChannel() 呼ばれる:

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

Why this matters: In older versions, setChannel() saved the channel override to the backend database (same as Dashboard or API changes). Devices had to wait for backend replication (up to 2 minutes) before the channel change took effect. Now, setChannel() を保存したチャンネルオーバーライドをバックエンドデータベース（同様にダッシュボードまたは__CAPGO_KEEP_0__の変更）に保存しました。デバイスは、チャンネル変更が有効になるまでバックエンドのレプリケーションを待つ必要がありました（最大2分）。今、

はバックエンドからのみ読み取り（検証用）し、ローカルに保存するため、チャンネル切り替えは即時になりました。 A channel set with the plugin does not make the device appear as a Device Override in the Capgo UI. Only channel assignments created from the dashboard or the Public API are listed there. Use the dashboard or API when you need an admin-visible override.

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

セキュリティの注意:

Method	チャンネルの権限がローカルに設定された後（たとえば、自己割り当てが無効になっている場合）でも、バックエンドは更新チェック中にチャンネルのバリデーションを実行し、セキュリティが維持されることを保証します。	チャンネル変更方法の比較:	デバイスオーバーライド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 の場合でも同じ機能が含まれます)。 プラグインのインストール https://plugin-install

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

ライブアップデートを展開するには、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.

Terminal window is not translated as it is a protected token. セマンティック バージョニングとCapgoのSemver テスター とチャンネル固有のビルド用のプレリリース識別子。例えば、ベータ リリースはバージョンとして 1.2.3-beta.1.

CIで、ローカル バージョンがすでにアップロードされていた場合、使用します npx @capgo/cli@latest bundle upload --auto-bump (任意の major, minor, patch/fix, metadata,または ai)でCLIがチャンネルのリンクされたバンドルからバージョンを上げるまで、空の名前が見つかるまで。 aiWorkers AIはローカル vs 前回のデルタ マニフェストからレベルを推測します (前回の__CAPGO_KEEP_0__バージョンがない場合に patch with no previous Capgo version). You cannot combine it with --bundleを組み合わせることはできません。詳細は CI/CD統合 と CLIリファレンス.

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

• ビルド間の関係を明確に伝えることができます。 1.2.3-beta.1 __CAPGO_KEEP_0__は明らかにプレリリースです。 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.4semverでプレリリース識別子を使用することは推奨されるアプローチですが、厳密には必要ではありません。重要なのは、ビルド間の関係を明確に伝え、チームの開発プロセスと一致するバージョニングスキームを見つけることです。

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

ロールバックしたいチャンネルの名前をクリック

channel: __CAPGO_KEEP_0__

1. , etc. __CAPGO_KEEP_1__
2. channel: __CAPGO_KEEP_0__
3. このアクションを確認します

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

自動デプロイ

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

自動化の詳細については、 CI/CD統合 docs to learn more about automating Capgo live updates.

最小権限のPRプレビュー

使用 App Preview 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キーを作成し、プレビュー用アプリに限定して選択するようにしてください。 App Preview. 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つのフローでプロモートします。クリーンアップは原子的で所有権をチェックします: キーは、自身が作成したチャンネルと紐付けられた、共有されていないバンドルをのみ削除できます。既存のメイン/デフォルトチャンネル、別のプレビューキーが所有するチャンネル、または別のキーが所有するバンドルを変更、プロモート、または削除することはできません。

レビューアが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, not pull_request_target, and restrict them to same-repository PRs with github.event.pull_request.head.repo.full_name == github.repository.

Deploying to a Device

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

1. Install the Capgo SDK in your app
2. アプリに__CAPGO_KEEP_0__ __CAPGO_KEEP_1__をインストールする必要があります。
3. アップロードしたビルドをそのチャネルに割り当てます。
4. アプリを起動し、更新を待ちます!

詳細なガイドについては、 ライブアップデートのデプロイ を参照してください。更新を楽しみましょう!

ユーザー セグメンテーションの高度なチャネル使用

チャネルは、開発段階のみに使用するものではありません。ユーザー セグメンテーションの強力なツールであり、以下のような機能を提供します。

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

これらの高度な用途を実装する方法を、以下のガイドで学びます: ユーザーをプランとチャンネルに基づいて分割する方法と、機能フラグとA/Bテストの方法.

チャンネルから続けて

チャンネルを使用している場合 チャンネル チャンネルと機能フラグ、A/Bテストのステージドロールアウトのルーティングを計画するには、Cloudflareの チャンネル チャンネルと機能フラグ、A/Bテストのステージドロールアウトの実装詳細については、Capacitorの チャンネル チャンネルと機能フラグ、A/Bテストのステージドロールアウトの実装詳細については、Capacitorの ベータテストソリューション Betaテストソリューションにおける製品ワークフローについて バージョン対象ソリューション バージョン対象ソリューションにおける製品ワークフローについて、 Capgo環境ベストプラクティス：1つのモバイルアプリIDでステージング Capgo環境ベストプラクティス：1つのモバイルアプリIDでステージングの実用的な背景について