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

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

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

ダウンロードサイズが小さい
ロールアウトが制御されている
何かが間違った場合に、リカバリが即時である

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

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

MAUが同じでも、スリムな構成は重要です

CapgoのCapgo機能の1つの便利な特徴は、Capgo MAUは、更新サービスに接続した月に有効なデバイスの数です。

スリムな構成は、MAUの数を減らすためのトリックではありません。実際にユーザーとチームが感じる部分を改善するため、重要です。

Faster downloads on cellular or weak Wi-Fi
Better experience with direct updates
Less wasted bandwidth on failed or rolled-back releases
Smaller blast radius when testing or staging a release

Lean updates are really about speed, safety, and operational discipline.

1. デルタ更新をデフォルトで設定する

Capgoを使用する場合、1つだけ実行することをおすすめします。

Capgo’s Deltaアップデート変更されたファイルのみを送信し、フルウェブパッケージを再ダウンロードするのではなく、バージョン間の差分を送信する。これは、定期的なOTAパフォーマンスの最大の単一の勝利です。

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

QAパスが完了したときは

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

CIが厳密に残るようにしたい場合は、 --delta-only 誰もが誤ってフルパッケージアップロードに戻るのを防ぐために

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

Deltaアップデートをサポートするプロダクションの艦隊がいる場合にのみ使用してください。 --delta-only 混合プラグインバージョンの場合、manifestベースのDelta配信をサポートしていない古いデバイスがアップデートをダウンロードできなくなります。

このことは、更新が見つかったときからアプリが再読み込まれたときの時間がユーザーに視覚化される場合にさらに重要です。 directUpdate2. アセットをアセットとして扱い、JavaScriptの荷物として扱わない

大きなアセットは、OTAバンドルが静かに膨らむ場所です。

2. アセットをアセットとして扱い、JavaScriptの荷物として扱わない。

実践的なルール:

JavaScript内に大きい画像やメディアをインライン化しないでください。通常のアセットファイルが代わりに機能する場合。
API またはCDNに頻繁に変更されるコンテンツを管理してください。アプリの配布パッケージ内に必要ない場合。
マーケティング画像、オンボーディングビデオ、リリースごとに置き換えられるキャンペーンアセットに注意してください。
安定したアセットは安定させてください。デルタアップデートでは、変更されていないファイルは再ダウンロードされるのではなく、再利用されます。

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

3. 本物のネイティブ変更用にネイティブリリースを維持してください。

Capgoは実行時ロードされるHTML、CSS、JavaScript、そしてアセットを更新します。

適切なチャネルではありません:

新しいネイティブプラグイン
許可の変更
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も適しています。 PR プレビュー. これにより、JS のみの変更をテストするために、製品、QA、ステークホルダーは新しい TestFlight または Play 内部ビルドを待つ必要がなくなります。

5. 直接更新を有効にすると、起動が重くなります

更新を適用する速度が速くしたい場合、起動パスはより規則正しくなければなりません。

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

docs notifyAppReady().

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

CapacitorUpdater.notifyAppReady()

アプリがデフォルトの10秒間、またはあなたが設定した__CAPGO_KEEP_0__設定内で、準備が完了しない場合、__CAPGO_KEEP_1__はそのバンドルを無効にし、前のバージョンに戻します。このロールバックの動作は、実稼働環境では望ましいですが、同時に起動時のクリーンさを保つ必要があります。 notifyAppReady() Call 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:

アプリを再読み込みした場合に、アプリの状態を保存して復元するには、注意してください。 notifyAppReady() 悪いネットワークや低性能デバイスのシナリオをテストする前に、広範囲に展開する前に
あなたが最近レビューしていない場合は、
notifyAppReadyのガイド
再度読む価値があります。

6. 内部の更新チャネルを使用するのではなく、不要なネイティブのリビルドを避ける 6. 不要なネイティブのリビルドを避けるために内部の更新チャネルを使用する 6. 内部の更新チャネルを使用するのではなく、不要なネイティブのリビルドを避ける

6. 内部の更新チャネルを使用するのではなく、不要なネイティブのリビルドを避ける

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

変更が:

コピー
UIのポリッシュ
オンボーディングフローの変更
価格表示画面のロジック
分析のワイヤリング
機能フラグ
質問または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の作業を移すことができます。テスト環境に1つのモバイルアプリID 実践的な方法でこれを長期にわたってきれいに保つ方法について説明しています。

7. 余分なものと秘密のものを分ける

小さなパッケージと安全なパッケージは異なる問題を解決します。

チャンネルは有効性を制御しますが、単独ではパッケージを機密情報にしないことになります。

より強力な配信保証が必要な場合:

有効にするライブアップデートの暗号化,
使用するカスタムストレージまたは自社ホストされた配信,
CIまたはセキュアなオペレーターフローのワークフロー内でのみプライベートキーを保持する

アップデートサイズは無視できないことではありません。ただし、両方の次元を最適化する必要があります:

スピードのために、
配信制御のために暗号化されます。
ロールアウト制御のためにチャンネルが使用されます。
リカバリのためにロールバックが使用されます。

実用的な「Capgo」ワークフロー

シンプルなデフォルトの運用モデルが必要な場合は、以下を使用してください。

ネイティブとOTAリリースレーンを分離してください。
デフォルトではJSの変更をアップロードしてください。 --delta チャンネルを使用してください。
と staging チャンネルを使用してください。 beta チャンネルを使用してください。 production.
Watch 更新統計とログロールアウト後ではなく、ロールアウト前に。
PRをインストール可能なプレビューに変換するには、ネイティブビルドが不要な場合。
__CAPGO_KEEP_0__ を除く大きな頻繁に変更されるメディアを可能な限りバンドルから外す。
主な資産の成長またはネイティブの変更後、ネイティブの基準を更新する。
Treat notifyAppReady() ロールバックの動作をリリースエンジニアリングの部分として扱うのではなく、セットアップのトリビアとして。

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

閉じた考え

「lean and fast」は、Capgo チームにとって、バンドルサイズの問題だけではありません。

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

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

How to Keep Capgo Updates Lean and Fast から続けてください。

Capgoを使用している場合 How to Keep Capgo Updates Lean and Fast を使用してチャネルルーティングとステージドロールアウトを計画するには、を連携してください。 Channels Channels Channels Channels Beta Testing Solution Beta Testing Solution Channels 製品ワークフローにおけるベータテストソリューション、およびバージョン目標ソリューション製品ワークフローにおけるバージョン目標ソリューション。