ユーザーが気づくことなくライブ更新を行うことは、最高の方法です。
通常、3 つのことが必要です:
- ダウンロードサイズが小さい
- ロールアウトが制御されている
- 何かが間違ってしまった場合に、リカバリが即時である
Capgoの「OTAをスリムに保つ」アドバイスは、React Nativeの世界でも有効ですが、CapgoはCapacitorチームにいくつかの追加のレバーを提供します。 __CAPGO_KEEP_1__は、, デルタ更新, チャンネル, 自動ロールバックバージョン目標 、オプションで使用できる「端末間暗号化」.
それらを組み合わせると、パッケージサイズが小さくなる、インストールが速くなる、運用上の混乱が少なくなる。
MAUが同じでも、スリムな構成は重要
Capgoの特有な一つ: Capgo MAUは、更新サービスに接続した月に活躍したデバイスの数であり、過去30日間で
スリムな構成は、MAUの数を減らすためのトリックではありません。実際にユーザーとチームが感じる部分を改善するためです。
- セルラーまたは弱いWi-Fiでダウンロードが速くなる
- 直接更新で 失敗したまたはロールバックされたリリースで浪費された帯域幅が少なくなる
- テストまたはステージングリリースの影響範囲が小さくなる
- スリムな更新は、速さ、安全性、運用上の規律についてです。
1. デルタ更新をデフォルトにする
あなたが一つだけ行うことができることを行う
あなたが一つだけ行うことができることを行う
Capgo’s Deltaアップデート 変更されたファイルのみを送信し、フルウェブパッケージをダウンロードするのではなく、バージョン間の差分を送信するようにします。これは、定期的なOTAパフォーマンスの最大の単一の勝利です。
bun run build
bunx @capgo/cli@latest bundle upload --channel staging --deltaQAパスが完了したとき:
bunx @capgo/cli@latest bundle upload --channel production --deltaCIが厳密に残るようにしたい場合は、 --delta-only 誰もが誤ってフルパッケージアップロードに戻るのを防ぐために:
bunx @capgo/cli@latest bundle upload --channel production --delta-onlyDeltaアップデートをサポートするプロダクションの艦隊が存在する場合にのみ使用してください。 --delta-only 混合プラグインバージョンで、manifestベースのDelta配信をサポートしていない古いデバイスがアップデートをダウンロードできないためです。
このことは、 directUpdateを使用する場合にさらに重要になります。
更新が見つかったときからアプリが再読み込みされるまでの時間がユーザーに視覚化されるようになります。
2. アセットをアセットとして扱い、JavaScriptの荷物として扱わない
Some practical rules:
- JavaScript内に大きな画像やメディアをインライン化しないでください。通常のアセットファイルを使用することができます。
- 頻繁に変更されるコンテンツは、API またはCDNに保管してください。アプリのバンドル内に配置する必要がない場合は、APIを使用してください。
- マーケティング画像、オンボーディングビデオ、リリースごとに置き換えられるキャンペーンアセットに注意してください。
- 安定したアセットは安定させてください。Delta更新では、変更されていないファイルは再ダウンロードするのではなく、再利用されます。
Capgoを高速に保つ最も簡単な方法の1つです。アプリが成長するにつれて、ユーザーに大量の無関係なメディアをダウンロードさせることなく、UIの小さな修正を実行できます。
3. 本物のネイティブ変更用にネイティブリリースを維持してください
Capgoは、実行時にロードされるHTML、CSS、JavaScript、そしてアセットを更新します。
以下は、__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 チャンネルシステム __CAPGO_KEEP_0__
stagingQA用beta招待されたテスター用production全員用hotfix緊急復旧用
シンプルなフローは次のようになります。
- アップロード先
staging. - 実機で検証する
- 制御されたチャンネルまたはパーセンテージベースのロールアウトを通じて段階的に展開する
- 健康率が低下した場合、すぐにロールバックする
野良のアプリが複数のネイティブベースラインを持っている場合、チャンネルをペアする バージョン対象. これにより、古いバイナリから非互換または不必要に重いバンドルが排除されます。
レビューループをさらに絞りたいチーム向けに、Capgoも適切に機能します。 PRプレビュー. これにより、JSのみの変更をテストするために、製品、QA、ステークホルダーは新しいTestFlightまたはPlayの内部ビルドを待つ必要がなくなります。
5. 直接更新を有効にすると、起動が重くなります
更新を適用する速度が速くしたい場合、起動パスはより規律を必要とします。
Capgoの 更新動作 docsは明示的にDelta更新と組み合わせることを推奨しています。 これは正しいデフォルトです。 directUpdate 2番目のガードレールは
The second guardrail is 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_KEEP_0__
- 高速化のためのスケールダウン
- 配信制御のための暗号化
- ロールアウト制御のためのチャンネル
A practical “lean Capgo” workflow
実用的な「__CAPGO_KEEP_0__」ワークフロー
- シンプルなデフォルトの運用モデルが必要なら、このようにしてください。
- ネイティブとOTAリリースのレーンを分離してください。
--deltaJSの変更を - デフォルトでは
stagingを使用してください。betaとチャンネルを使用してください。production. - Watch 更新統計とログ ロールアウト後ではなく、ロールアウト前に。
- PRをインストール可能なプレビューに変換するには、ネイティブビルドが不要な場合。
- __CAPGO_KEEP_0__ の場合、可能な限りバンドルから大きな頻繁に変更されるメディアを除外する。
- ネイティブの基準を更新するには、主な資産の成長やネイティブの変更が必要。
- Treat
notifyAppReady()ロールバックの動作は、セットアップのトリビアではなく、リリースエンジニアリングの一部として扱う。
その組み合わせは、一般的な「変更したものだけをアップロードする」アプローチよりも、長く速く維持される。
閉じた考え
「軽量で速い」は、Capgo チームにとって、単にバンドルサイズの問題ではありません。
それはリリース設計の問題です。
データサイズの場合、Delta更新を使用し、ロールアウトサイズの場合、チャンネルを使用し、失敗サイズの場合、ロールバックを使用します。OTAについて考えるときにそう考えると、更新が速くなります。アプリ、チーム、ユーザーが増えても、更新は速くなります。
How to Keep Capgo Updates Lean and Fast から続けてください。
「を使用している場合 How to Keep Capgo Updates Lean and Fast を計画するチャネルルーティングとステージドロールアウトに接続するには チャンネル チャンネル チャンネル チャンネル ベータテストソリューション Beta Testing Solution Channels ベータテストソリューションにおける製品ワークフローについて、 バージョン対象ソリューション バージョン対象ソリューションにおける製品ワークフローについて。
