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

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

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

最初の2つは機能しますが、長期的な摩擦を生み出します。実際のチームでは、Capgo チャネルモデルは通常、最も綺麗です。

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

使用する com.myapp そして com.myapp.beta 簡単に思えるが、すぐに複製が発生します:

2 つのリリース Pipelines
2 つのプッシュ ID、ディープリンク、およびエンタイトルメントマッピング
2 つの分析とクラッシュ ID
環境間で不一致な構成と動作

ストアコンソール、チーム、および内部 QA 指示の管理が 2 つの製品に発展します。

実行時で構成を切り替えるのはよくない

「1 つのアプリ ID + 実行時切り替え」パターンは、通常、起動時に環境変数またはフラグを読み取り、API、キー、および更新動作をダイナミックに再設定します。

This works until:

QAが予定外のフローを回避するようになったのは、configの状態が古いからです。
実際のエンドポイントを使用してプロダクションでエラーが発生する
環境の変化が再現が難しいバグを引き起こす
ユーザーのデバイスで「このバイナリが使用しているconfigのバージョンは何ですか？」というデバッグが必要になります。

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

The Capgo way: one app ID, many channels

Capgo makes environment control explicit through channels:

App Store/Playで1つのプロダクションアプリIDを維持してください。
「シェル」のためのネイティブバイナリを1つ配信してください (ネイティブの変更が真の再構築を必要とするまで)。
チャネルによってではなく、重複したアプリのIDによって動作をルーティングしてください。

実際には、これは次のことを意味します:

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

Your TestFlight/Play 内部テストアプリは、 staging .forever. あなたはJS/CSS/アセットの更新をCapgoで繰り返し行うことができます。新しいネイティブアプリを公開する必要はありません。

実践における推奨構造

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

あなたの最後のネイティブバイナリは、多くのJSの反復で同じままです:

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

あなたは実際にネイティブの表面領域が変更された場合にのみ、ネイティブバイナリを再構築します。

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

チャネルを使用して更新を公開する:

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

QA環境でテスト、問題を修正し、次にプロモート:

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

バージョン指定を明示する場合:

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

3) TestFlightを「常にプレプロダクション」に設定する

iOSワークフローでは、TestFlightビルドはプレプロダクションの更新と関連付けられる:

JSの変更ごとに頻繁にネイティブのサブミットは必要ない。
QAは、ステージングチャンネルを介して近似的なプロダクションcodeを検証する。
プロダクションユーザーはのみプロモートされたプロダクションチャンネルパッケージを受信する。

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

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

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

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

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

運用チェックリスト

1つのアプリIDのみ（プロダクション/ステージングの重複IDなし）
native buildパイプラインのベースライン
Channelマッピングドキュメント（staging, beta, production, hotfix)
CI/CDでPromotionパスを強制
nativeリビルドはtrue native変更のみ
Rollbackは定期的にテスト

実用的な利点

このアプローチは環境ドリフトを排除し、ビルドの混乱を軽減し、修正を速める：

QAはリアルなバイナリを取得（「ステージングアプリ」偽のアイデンティティなし）、
TestFlightパスは安定し
チームは「2つのアプリIDの負債」を避ける
JSのみの修正をCapgoで迅速に推し進めることができる

結果としては、よりシンプルな統治が実現：アーティファクトが減り、テレメトリが綺麗になり、リリースオペレーションにおける驚きが減る