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

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

2つのアプリID(生産+前期生産)
1つのアプリID + 動的実行環境切り替え
1つのアプリID + Capgo チャンネル

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

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

使用 com.myapp そして com.myapp.beta __CAPGO_KEEP_0__が簡単に見えますが、すぐに複製が発生します。

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

ストアコンソール、チーム、および内部 QA 指示書を跨いだ 2 つの製品を管理することになります。

実行時で構成を切り替えることがよく汚くなる理由

「1 つのアプリ ID + 実行時切り替え」パターンは、起動時に環境変数またはフラグを読み取り、API、キー、および更新動作を動的に再設定することを意味します。

これは、次のまで機能します。

QA が構成状態が古いので、意図されたフローを回避するようになります。
誰かが、間違ったエンドポイントをプロダクションで使用する
環境の変化が、再現が困難なバグを引き起こします。
ユーザーデバイスで「このバイナリはどの構成バージョンを使用しているか？」というデバッグが必要です。

リリースごとに複雑さが増し、チームは速度を失います。

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緊急修正トラック

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

実践における推奨構造

1) ネイティブリリース基準

JS イテレーションが多くても、最後のネイティブバイナリは同じままです。

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

native binary を実際に変更した場合のみ再構築します。

2) 環境ごとに専用のチャネルを使用してください。

アップデートをチャンネルで公開する

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

テスト環境でテスト、問題を修正し、次にリリース:

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) テストフライトを常に「プレプロダクション」モードで実行してください。

iOS ワークフローでは、このことは、テストフライトのビルドがプレプロダクションのアップデートと関連付けられることを意味します。

JSの変更ごとに頻繁なネイティブの提出がない。
QAは、プロダクションに近いcodeをステージングチャンネル経由で常に検証する。
プロダクションユーザーは、プロモートされたプロダクションチャンネルバンドルを受け取るのみ。

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

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

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

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

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

運用チェックリスト

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

実用的な利点

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

QAはリアルなバイナリを取得 (「ステージングアプリ」の偽のアイデンティティなし)
あなたのTestFlightパスは安定する
あなたのチームは「2つのアプリIDの負債」を避ける
あなたはCapgoで迅速に多くのJSのみの修正をプッシュできる

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

Capgo Environment Best Practices: Staging with One Mobile App IDから続けて

あなたが「__CAPGO_KEEP_0__ Environment Best Practices: Staging with One Mobile App ID」を使用してチャンネルルーティングとステージドロールアウトを計画している場合 Capgo Environment Best Practices: Staging with One Mobile App IDを接続する __CAPGO_KEEP_0__ チャンネル __CAPGO_KEEP_0__ チャンネル __CAPGO_KEEP_0__ チャンネル __CAPGO_KEEP_0__ ベータテストソリューション __CAPGO_KEEP_0__ バージョンターゲットソリューション __CAPGO_KEEP_0__

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