How to Keep Capgo Updates Lean and Fast

最も良いライブ更新は、ユーザーが気づかなかったものです。

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

ダウンロードサイズが小さい
ロールアウトが制御されている
エラーが発生した場合に、リカバリが即時である

The same “keep OTA lean” advice that works in React Native land also applies to Capgo. The difference is that Capgo gives Capacitor teams a few extra levers: デルタ更新, チャンネル, 自動ロールバック, バージョン対象、およびオプション端末間暗号化.

Capgoを使用する場合、パフォーマンスが向上し、インストールが速くなり、運用上の混乱が少なくなります。

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

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.

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

セルラーまたは弱いWi-Fi環境でのダウンロードが速くなります。
直接の更新により、失敗したまたはロールバックされたリリースで浪費された帯域幅が減ります。
テストまたはステージングリリースの場合、爆発半径が小さくなります。
軽量化された更新は、速度、安全性、運用上の規律についてです。

1. デルタ更新をデフォルトとして設定する

1つのことを実行するなら、このようにしてください。

__CAPGO_KEEP_0__は__CAPGO_KEEP_1__です。

Capgoのデルタアップデートファイルの変更のみを送信し、フルウェブパッケージを再ダウンロードするのではなく。これは、定期的な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 デルタアップデートをサポートするプロダクションフリートが存在する場合にのみ使用してください。混合プラグインバージョンの場合、古いデバイスがマニフェストベースのデルタ配信をサポートしていない場合、更新をダウンロードできません。

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

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

__CAPGO_KEEP_0__

実践的なルール:

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

これは、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のチャンネルシステムそれは、以下の制御の最も清潔な方法です:

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

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

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

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

Capgoのアップデートをスリムかつ高速に保つには、チームがより厳密なレビューループを望む場合も、Capgoが適しています。 PRプレビュー. これにより、JSのみの変更をテストするために、製品、QA、ステークホルダーが新しいTestFlightまたはPlayの内部ビルドを待つ必要なく、JSのみの変更をテストできます。

5. 直接アップデートを有効にすると、起動ハードを最適化する

アップデートを適用する速度が速いほど、起動パスがより規則正しくなければなりません。

Capgoのアップデートの動作のドキュメントでは、Deltaアップデートと組み合わせることを明示的に推奨しています。それが正しいデフォルトです。 directUpdate 2番目のガードレールは

__CAPGO_KEEP_0__ notifyAppReady().

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

CapacitorUpdater.notifyAppReady()

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

呼び出し notifyAppReady() コンテキスト: Appflow Migration Step2
正しい場所で呼び出します。
重要なパスで遅い起動時間の作業を避けます。
アプリの状態を保存して復元する際は、即座にリロードする場合は注意してください。

悪いネットワークや低エンドデバイスのシナリオをテストする前に、広範囲に展開する前に。あなたが最近レビューしなかった場合、notifyAppReadyガイドは再度読む価値があります。 6. 内部の更新チャネルを使用するのではなく、不要なネイティブのビルドを避けます。

__CAPGO_KEEP_0は設定ファイルです。CAPGO_KEEP_1__はCapgoの機能です。

A lot of mobile teams waste time building binaries for changes that are clearly web-only.

変更が:

コピー
UIの改善
導入フローの改善
価格表示画面のロジック
分析の設定
機能フラグ
質問やAPIのレスポンスのレンダリング

すると、Capgoのアップデートはよくレビューできるアーティファクトになります。

つまり、ネイティブのビルドが少なくなるので、TestFlightの変動が少なく、チームのフィードバックループが短くなります。これはCapgoの最も利用されていない利点の1つです: ネイティブ/ウェブの境界を破ることなく、OTAのレーンにレビューとQAの作業を移すことができます。

Capgoのガイドステージングに1つのモバイルアプリID この方法は実践的なもので、長期にわたってクリーンな状態を維持する方法をカバーしています。

7. リーンとシークレットを分離する

小さなバンドルとセキュアなバンドルは異なる問題を解決します。

チャンネルは有効性を制御します。チャンネル自体がバンドルを機密情報にしないからです。

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

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

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

スピード向上のための "軽量化"
配信制御のための暗号化
ロールアウト制御のためのチャネル
復旧のためのロールバック

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

シンプルなデフォルトの運用モデルを簡単に実現したい場合は、以下を使用してください。

ネイティブとOTAリリースの分離を実行します。
デフォルトではJSの変更をアップロードします。 --delta デフォルトでは
チャネル staging と beta チャネルを事前に production.
動画を視聴する更新の統計とログを確認するロールアウト後ではなく、ロールアウト前に
PRをインストール可能なプレビューに変換する。ネイティブビルドが不要な場合。
可能な限り、頻繁に変更される大きなメディアをバンドルから除外する。
ネイティブの基準を更新する。ネイティブの変更や大きなアセットの成長が発生した場合。
扱う notifyAppReady() とロールバックの動作は、リリースエンジニアリングの問題であり、セットアップのトリビアではありません。

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

閉じる言葉

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

リリース設計の問題です。

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

CapgoのCapgoの更新をスッキリと速くする方法から続きます。

Capgoを使用している場合 CapgoのCapgoの更新をスッキリと速くする方法 チャンネルルーティングとステージドロールアウトを計画するには、Capgoの__CAPGO_KEEP_0__を連携してください。チャンネル Capgoのリリースチャンネル機能名。ページ/エリア: Capgoのソリューションズマーケティングページ。ロール: 短いUIラベルまたはナビゲーションアイテム。見られる場所: page solutions/white-label.astro。メッセージキー `solutions_white_label_visual_cell2_value` (ソリューションズホワイトラベルビジュアルセル2値)。チャンネル Capgoのリリースチャンネル機能名。ページ/エリア: Capgoのソリューションズマーケティングページ。ロール: 短いUIラベルまたはナビゲーションアイテム。見られる場所: page solutions/white-label.astro。メッセージキー `solutions_white_label_visual_cell2_value` (ソリューションズホワイトラベルビジュアルセル2値)。チャンネル Capgoのリリースチャンネル機能名。ページ/エリア: Capgoのソリューションズマーケティングページ。ロール: 短いUIラベルまたはナビゲーションアイテム。見られる場所: page solutions/white-label.astro。メッセージキー `solutions_white_label_visual_cell2_value` (ソリューションズホワイトラベルビジュアルセル2値)。チャンネルルーティングとステージドロールアウトを計画するには、Capgoの__CAPGO_KEEP_0__を連携してください。 Beta Testing Solutionの製品ワークフローについてバージョン目標ソリューションバージョン目標ソリューションの製品ワークフローについて

Capgoの更新をスリムかつ高速に維持する方法