Capgoのリアルタイム更新をスリムで速く維持する方法

最も良いライブ更新は、ユーザーがほとんど気づかないものです。

通常、3 つのことが必要です:

ダウンロードサイズが小さい
ロールアウトが制御されている
Recovery is instant if something goes wrong.

Capgoの「OTAの軽量化」アドバイスは、React Nativeの世界でも有効です。ただし、Capgoは、Capacitorチームにいくつかの追加のレバーを提供します。 Delta更新, チャンネル, 自動ロールバック, バージョン対象、オプションのエンドツーエンド暗号化.

これらを組み合わせると、パッケージサイズが小さくなる、インストールが速くなる、運用上の混乱が少なくなる

MAUが同じでも、軽量化は重要です

Capgoの特徴的な詳細: CapgoのMAUは、更新サービスに接続した月に活躍したデバイスの数に相当します。

したがって、バンドルの削減は、MAUのカウントを減らすためのトリックではありません。重要なのは、ユーザーとチームが実際に感じる部分を改善することです。

携帯電話または弱いWi-Fiで高速ダウンロード
直接更新でより良いエクスペリエンス
失敗したまたはロールバックされたリリースで浪費されたバンド幅が少なくなる
テストまたはステージングリリースの場合の影響範囲が小さくなる

Lean更新は実際にはスピード、セーフティ、オペレーショナルディスコースのことです。

1. デルタ更新をデフォルトにする

あなたが一つだけ行うことができることを行うなら、これが一番です。

Capgoのデルタ更新バージョン間で変更されたファイルのみを送信するのではなく、フルウェブパッケージを再ダウンロードするのではなく、

bun run build
bunx @capgo/cli@latest bundle upload --channel staging --delta

定期的なOTAパフォーマンスのために最大の単一の勝ちとなるのは、

bunx @capgo/cli@latest bundle upload --channel production --delta

CIが厳密に残すには --delta-only CIが厳密に残すには、

bunx @capgo/cli@latest bundle upload --channel production --delta-only

Capacitorで --delta-only Capacitorで、プロダクションの艦隊がDeltaアップデートをサポートしている場合にのみ使用してください。

Capacitorで directUpdateCapacitorで、プロダクションの艦隊がDeltaアップデートをサポートしている場合にのみ使用してください。

Capacitorで

Capacitorで、プロダクションの艦隊がDeltaアップデートをサポートしている場合にのみ使用してください。

Capacitorで

Capacitorで、プロダクションの艦隊がDeltaアップデートをサポートしている場合にのみ使用してください。
Keep frequently changing content on your own CDN or API if it does not need to live inside the shipped app bundle.
Capacitorで、プロダクションの艦隊がDeltaアップデートをサポートしている場合にのみ使用してください。
安定したアセットは安定するように。Deltaの更新では、変更されていないファイルは再ダウンロードされるのではなく、再利用される。

Capgoをアプリが成長しても速く保つ最も簡単な方法の1つです。最悪のパターンは、ユーザーに大量の無関係なメディアをダウンロードさせるために、UIの小さな修正です。

3. 実際のネイティブ変更用にネイティブリリースを維持する

Capgoは、HTML、CSS、JavaScript、実行時ロードされたアセットのWeb層を更新します。

これは適切なチャネルではありません。

新しいネイティブプラグイン
許可の変更
capacitor.config.ts 変更
iOSまたはAndroidネイティブプロジェクトの状態を変更するもの

その行もパフォーマンスに影響します。OTAのレーンに主な構造的変更を繰り返し追加すると、更新戦略が重くリスクが高くなります。

目的で2つのリリースレーンを使用する

ネイティブレーン

プラグインの変更、権限の変更、ネイティブの設定:

bun run build
bunx cap sync

通常のストアのリリースを出荷する。

Capgo レーン

安全なウェブ層の反復:

bun run build
bunx @capgo/cli@latest bundle upload --channel production --delta

最近多くの長期間の資産を追加した場合、常にネイティブの基準を更新してください。新しいストアのビルドでは、その新しい基準を埋め込みます。これにより、将来の Capgo の差分が小さくなります。

4. チャンネルを使用してロールアウトのサイズを小さくします。

「スリム」な更新は、単にメガバイトだけではありません。更新が良いかどうかを知る前に、多くのデバイスが更新を受け取ることにも関係します。

Capgo のチャンネルシステムは、更新を受け取るデバイスの数を制御する最も綺麗な方法です。

staging QA
beta 招待されたテスター
production 全てのユーザー向け
hotfix 緊急復旧用

シンプルなフローは次のようになります:

アップロード staging.
実機で検証
制御チャネルまたはパーセンテージベースのロールアウトを通じて、徐々に展開
健康率が低下した場合、即時ロールバック

あなたのアプリが複数のネイティブベースラインを公開している場合、バージョン対象古いバイナリから不必要な重いパッケージを排除するため、

レビューループがさらに厳密に必要なチーム向けに、Capgoも効果的プルリクエストのプレビュー. では、製品、QA、そして利害関係者は、TestFlight または Play 内部ビルドを待たずに JS のみの変更をテストできます。

5. 直接更新を有効にすると、起動が遅くなる可能性があります

更新が適用される速度が速いほど、起動パスがより規律的にならなければなりません。

Capgo’s 更新の動作 docs は明示的に、Delta の更新と組み合わせることを推奨しています。それは正しいデフォルトです。 directUpdate 2 番目のガードレールは

アプリがデフォルトの 10 秒間のウィンドウ内、またはあなたが __CAPGO_KEEP_0__ の設定で指定した時間内に、準備ができていない場合、__CAPGO_KEEP_1__ はそのバンドルを無効にし、前のバージョンに戻します。そのロールバックの動作は、生産環境では望ましいですが、起動がきれいであることを保証する必要があります: notifyAppReady().

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

CapacitorUpdater.notifyAppReady()

起動を呼び出す notifyAppReady() __CAPGO_KEEP_1__ appReadyTimeout you set in your Capacitor config, Capgo can mark that bundle invalid and restore the previous good version. That rollback behavior is what you want in production, but it also means you should keep startup clean:

__CAPGO_KEEP_0__ notifyAppReady() 正しい場所に
重要なパスで遅い起動時間の作業を避ける
アプリを再読み込みするとすぐにアプリの状態を保存して復元するには、注意してください
広範囲に展開する前に、悪いネットワークと低エンドデバイスのシナリオをテストする

最近のレビューをしていない場合は、 notifyAppReadyのガイド読む価値があります。

6. 内部の更新チャネルを使用する代わりに、不要なネイティブのビルドを避ける

多くのモバイルチームは、明らかにWebのみの変更に対して、明らかに時間を浪費してビンナリをビルドしています。

変更が:

コピー
UIのポリッシュ
onboarding フロー
価格表示画面のロジック
分析のワイヤリング
機能フラグ
API への回答の表示

Capgo のアップデートは、レビューのアーティファクトとしては速いことが多い。

That means fewer native rebuilds, less TestFlight churn, and a tighter feedback loop for the team. It is one of the most underused benefits of Capgo: you can move more review and QA work into the OTA lane without breaking the native/web boundary.

__CAPGO_KEEP_0__ の最も利用されていない利点の 1 つは、OTA のレーンでレビューと QA の作業を移動できることです。ネイティブ/ウェブの境界を破壊することなく。 Capgo のガイド 1 つのモバイルアプリ ID でステージング

このことを長期的に維持するための実用的方法をカバーしています。

7. リーンなものとシークレットを分ける

__CAPGO_KEEP_0__のチャンネルは、資格を制御します。彼ら自身ではバンドルを機密扱いにすることはありません。

__CAPGO_KEEP_1__が必要な場合:

__CAPGO_KEEP_2__ Live Updateの暗号化,
__CAPGO_KEEP_3__ CIまたはセキュアなオペレーターのワークフローで、プライベートキーを保持するのみで十分です。,
更新サイズは無視できません。ただし、両方の要素を最適化する必要があります:

__CAPGO_KEEP_4__

__CAPGO_KEEP_5__
__CAPGO_KEEP_6__
__CAPGO_KEEP_7__.
__CAPGO_KEEP_8__

実践的な「Capgo」フロー

このシンプルなデフォルトの運用モデルを使用する場合は、次のとおりです。

ネイティブとOTAリリースチャンネルを分離してください。
JSの変更を --delta デフォルトでは
を使用して staging と beta チャンネルを使用する前に production.
を監視してロールアウト後に統計とログを更新するのではなく、単にそれらを監視するのではなく。ネイティブビルドが不要な場合は、PRをインストール可能なプレビューに変換してください。
チャンネルを使用する前に、
可能であれば、大量の頻繁に変更されるメディアをバンドルから外す。
主なアセットの増加やネイティブの変更後、ネイティブの基準を更新する。
「Treat」 notifyAppReady() 「and rollback behavior」はリリースエンジニアリングの問題であり、セットアップのトリビアではありません。

その組み合わせは、一般的な「変更したものだけをアップロードする」アプローチよりも長く速いままになります。

閉じる言葉

For Capgo teams, “lean and fast” is not just a bundle-size problem.

それはリリース設計の問題です。

ペイロードサイズではDeltaアップデートを使用し、ロールアウトサイズではチャンネルを使用し、エラーサイズではロールバックを使用します。OTAについて考えるときにそう考えると、更新はアプリ、チーム、ユーザベースが大きくなるにつれても速くなります。

Keep going from How to Keep Capgo Updates Lean and Fast

Capgoを使用している場合 How to Keep Capgo Updates Lean and Fast チャンネルルーティングとステージドロールアウトを計画するには、 __CAPGO_KEEP_0__ チャンネルの実装詳細については、 __CAPGO_KEEP_0__ チャンネルの実装詳細については、 __CAPGO_KEEP_0__ ベータテストソリューションベータテストソリューションにおける製品ワークフローについては、バージョン目標ソリューションバージョン目標ソリューションにおける製品ワークフローについては、 Written by