Capgo 環境ベストプラクティス：ステージングに1つのモバイルアプリIDを使用

チームは通常、モバイル環境のために3つのアプローチのうち1つを選択します。

2つのアプリID（生産+プレプロダクション）
1つのアプリID + 動的実行環境切り替え
1つのアプリID + Capgo チャンネル

最初の2つは機能するかもしれませんが、実際のチームではCapgo チャンネルモデルが通常最も綺麗です。

重複したアプリIDがノイズになる理由

「{0}」と「{1}」を使っています。 com.myapp 簡単に思えるかもしれませんが、すぐに複製が発生します。 com.myapp.beta 2 つのリリースパイプライン

2 つのプッシュID、ディープリンク、エンタイトルメントマッピング
2 つの分析とクラッシュID
環境間で構成と動作が不一致になる
ストアコンソール、チーム、内部のQA指示書を通じて2つの製品を管理することになります。

ランタイム切り替えの構成が混乱する理由

「1 つのアプリID + ランタイム切り替え」パターンは、起動時に環境変数またはフラグを読み取り、API、キー、更新動作をダイナミックに再ルーティングすることを意味します。

これは、以下の場合に機能します:

これは、以下の場合に機能します:__CAPGO_KEEP_0__

QAは意図されたフローを回避するよう始めます。config stateが古くなっているからです。
someoneがproductionで間違ったエンドポイントを使用する
環境の変化が難しいバグを引き起こします。
ユーザーのデバイスで「このバイナリが使用しているconfigバージョンは何ですか？」というデバッグが必要になります。

これらの複雑さはリリースごとに増加し、チームの速度が低下します。

The Capgo way: one app ID, many channels

Capgoはチャンネルを通じて環境の制御を明示的に行います。

App Store / Playで1つのproduction app IDを維持します。
nativeバイナリの「シェル」(nativeの変更がtrueのリビルドを必要とするまで)を1つに配信します。
チャンネルによってではなく、重複したアプリのIDによって動作をルーティングします。

実際には、以下のようになります。

production:すべてのユーザー
staging: 内部QAとリリース候補
beta: 招待されたテスター
hotfix: 緊急パッチトラック

Your TestFlight/Playの内部テストアプリは staging .forever. You do JS/CSS/アセットの更新をCapgoで繰り返し、新しいネイティブアプリを公開することなく実行できます。

実践における推奨構造

1) ネイティブリリースベースライン

Your last native binary stays the same for many JS iterations:

bun run build
bunx cap sync
# generate Xcode/Android Studio archives as usual

You only rebuild the native binary when you actually changed native surface area.

2) 環境用に専用のチャンネルを使用する

Publish updates with channels:

bun run build
bunx @capgo/cli deploy --channel staging

Test on QA、fix issues、then promote:

bunx @capgo/cli promote vX.Y.Z --channel production

If you prefer explicit versioning:

bunx @capgo/cli deploy vX.Y.Z --channel staging
bunx @capgo/cli promote vX.Y.Z --channel production

3) TestFlight “always pre-prod”を常に保持する

In iOS workflows, this means your TestFlight build can stay associated with pre-production updates:

JSの変更ごとに頻繁にネイティブのサブミッションは必要ありません。
QAはステージングチャンネルを通じて、近似的なcodeのプロダクションバージョンを検証します。
プロダクションユーザーはのみ、プロモートされたプロダクションチャンネルバンドルを受け取ります。

4) 制御されたワークフローでのチャンネル切り替えのみを使用する

高度なチーム向けに、QA管理ユーザー向けに制御されたチャンネル切り替えを公開する

import { CapacitorUpdater } from '@capgo/capacitor-updater';

await CapacitorUpdater.setChannel({
  channel: 'staging',
  triggerAutoUpdate: true
});

これはオプションです。多くのチームはダッシュボードからチャンネル割り当てを使用し、すべての顧客ではなく内部ユーザーのみにチャンネルを切り替えます。

運用チェックリスト

アプリIDは1つだけ (プロダクション/ステージングのIDは重複しない)
ネイティブのビルドパイプラインは1つだけ (ベースライン)
チャネルマッピングドキュメント (staging, beta, production, hotfix)
CI/CDでプロモーションパスが強制されます
ネイティブ再構築は、実際のネイティブ変更のみに
ロールバックは定期的にテストされます

実用的な利点

このアプローチは、環境の漂流を排除し、ビルドの混乱を減らし、修正を速める:

QAはリアルなバイナリを取得します（偽の「ステージングアプリ」アイデンティティなし）、
テストフライトのパスは安定しています
チームは「2つのアプリIDの負債」から逃れます
あなたはCapgoで迅速に多くのJSのみの修正をプッシュできます。

最終的な結果は、よりシンプルな統治: 少ないアーティファクト、きれいなテレメトリ、リリースオペレーションの驚きが少なくなります。

Capgo 環境ベストプラクティス：1つのモバイルアプリIDでステージング