Capgoをリアルタイム更新で軽量に保つ方法

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

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

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

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

日本語の対象言語

Cloudflare

One useful Capgo-specific detail: Capgo MAU is effectively the number of monthly active devices that contacted the update service in the last 30 days.

GitHub

Capgo
code API
SDK
CLI

npm

bun

使用する場合、パッケージサイズが小さくなる、インストールが速くなる、運用上の混乱が少なくなる。

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-only 、を使用する場合にさらに重要です。

2. アセットをアセットとして扱う directUpdate大きなアセットは、OTAバンドルが静かに膨張する場所です。

Only use when your production fleet supports Delta updates.

This matters even more if you use

Some practical rules:

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

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

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

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

以下は、__CAPGO_KEEP_0__の適切なチャネルではありません。

新しいネイティブプラグイン
許可の変更
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’s チャンネルシステムそのような制御は、以下の方法で行うことができます:

staging QA用
beta 招待されたテスター用
production 全員用
hotfix 緊急回復用

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

アップロード staging.
実機で検証する。
段階的に展開する。コントロールチャンネルまたはパーセンテージベースの展開を使用する。
健康が低下すると、すぐにバックアップする。

あなたのアプリが複数のネイティブベースラインを持っている場合、チャンネルをペアする。バージョン対象. これは、古いバイナリから不必要なバンドルを排除するために使用されます。

レビューループをさらに絞り込みたいチーム向けにも、Capgoが適しています。 PR プレビュー. これは、JS のみの変更をテストするために、TestFlight または Play の内部ビルドを待つ必要がなくなるため、製品、QA、ステークホルダーが JS のみの変更をテストできます。

5. 直接更新を有効にすると、起動が速くなるように、起動パスを厳格に制御する必要があります。

__CAPGO_KEEP_0__の

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

The second guardrail is notifyAppReady().

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

CapacitorUpdater.notifyAppReady()

If your app does not report ready within the default 10-second window, or within whatever you set in your __CAPGO_KEEP_0__ config, __CAPGO_KEEP_1__ 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() 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:

Boot timeの処理を避ける notifyAppReady() アプリの状態を保存して復元する際は、即時リロードの場合に注意
ネットワークの不良や低性能デバイスのシナリオをテストする
notifyAppReady guide
は最近確認していない場合は、再度読む価値があります。

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_KEEP_0__
高速化のためのスケールダウン
配信制御のための暗号化
ロールアウト制御のためのチャンネル

A practical “lean Capgo” workflow

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

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

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

閉じた考え

Capgoチームにとって、「軽量で速い」は単にバンドルサイズの問題ではありません。

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

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

Capgoの更新を軽快に保つ方法についてはここから続きます。

「__CAPGO_KEEP_0__」を使用している場合 Capgoの更新を軽快に保つ方法についてはここから続きます。 __CAPGO_KEEP_0__を使用してチャネルルーティングとステージドロールアウトを計画するには、__CAPGO_KEEP_0__を「チャネル」に接続します。「チャネル」「チャネル」「チャネル」「チャネル」「チャネル」ベータテストソリューション Beta Testing Solution ベータテスト解決策の製品ワークフローについて、バージョン目標解決策バージョン目標解決策の製品ワークフローについて。