天気
Windy.com - 天気予報
地図、アラート、ナビゲーションの修正など、慎重な本番環境への展開が求められる天気アプリ。
- Google Play インストール数
- 3,290万
- ストア評価
- 4.7
本番アップデート
すべてのユーザーに最新の修正を即座に適用
CLIやCIから新しいWeb bundleをupload。デバイスはバックグラウンドでダウンロードし、アプリがフォアグラウンドに戻った際に実行します。リリース率をパーセンテージで制御し、Observeで状況を監視。問題が発生した場合はすぐにロールバックできます。
クレジットカード不要
自動ロールバック機能を搭載
Webレイヤーのアップデートのみ
課題
ストア経由のリリースは、小さな修正を届けるには時間がかかりすぎます
ストアのみの修正フロー
1
バグの特定
モニタリングやサポートから画面の不具合が報告されます。修正は数行のJavaScriptやCSSで済みます。
2
新しいバイナリのビルド
バージョンを上げ、iOSとAndroid向けにビルドし、2つのストア申請を準備します。
3
レビュー待ち
ストアのレビューには通常24〜48時間、時にはそれ以上かかります。リジェクトされると、また待ち時間が最初から始まります。
4
ユーザーのアップデート待ち
承認後も、各ユーザーが新しいバージョンをインストールする必要があります。それまでは、古い code が実行されたままです。
各ステップが、修正の準備ができてからユーザーのデバイスに適用されるまでのタイムラグを生んでいます。
ストア経由の修正がユーザーに届くのが遅い理由
24–48時間+
一般的なストア審査時間
AppleとGoogleは新しいバイナリをすべて審査します。審査には通常24〜48時間、時にはそれ以上かかり、リジェクトされると再申請が必要になります。
ユーザーあたり
ストアの更新はデバイスごとに異なります
ストアのアップデートは、ユーザーまたは自動更新設定によってインストールされて初めてデバイスに適用されます。一部のデバイスでは、古いビルドのまま長期間使い続けられることがあります。
2つのストア
修正のたびに2回の申請が必要
同じWebの修正でも、App StoreとGoogle Playに個別に申請する必要があり、それぞれに独自の審査とリリースプロセスが発生します。
ソリューション
live update がユーザーに届く仕組み
これは Capgo のデフォルトのアップデート動作です。アップデートのプロンプト表示や強制再起動、Webレイヤーの変更に伴うストアへの再申請は一切不要です。
標準的なアップデートフロー
-
アプリがアップデートを確認します
アプリがフォアグラウンドに移行した際、およびアプリ起動中は10分ごとに、アップデーターがCapgoに対して対象チャネルの最新bundleをリクエストします。
フォアグラウンド時
-
バックグラウンドでダウンロード
ユーザーが現在のバージョンを使用している間に、新しいbundleをダウンロードします。delta updatesを使用すれば、変更されたファイルのみをダウンロード可能です。
中断なし
-
次回のレジューム時に切り替え
ユーザーがアプリを終了した際に、アップデーターがbundleをインストールします。次にアプリを開いたときには、新しいバージョンが実行されます。
次回のフォアグラウンド時
アプリ起動直後に新バージョンを適用したいですか？Direct updateモードなら、スプラッシュ画面が表示されている間に起動時に適用できます。
Direct updatesを見る仕組み
Capgo を使ったプロダクションチームの修正デプロイ方法
すでにストアに公開されている Capacitor アプリの一般的なリリースフローです。以下のコマンドはすべて Capgo CLI ドキュメントに基づいています。
-
アップデーターの初期設定
セットアップウィザードを実行し、アプリ起動後に notifyAppReady() が確実に呼び出されるようにします。この関数が一度も呼び出されない bundle は、自動的にロールバックされます。
notifyAppReady() のドキュメントnpx @capgo/cli@latest init # in your app start-up code await CapacitorUpdater.notifyAppReady() -
修正版を一部のプロダクション環境へアップロード
--delta を使用して変更されたファイルのみを取得させ、--rollout を使って少数のデバイスから展開を開始します。それ以外のユーザーは安定した bundle を使い続けます。
プログレッシブ・ロールアウトのドキュメントnpx @capgo/cli@latest bundle upload --channel production --delta --rollout 5 -
Capgo による不具合のあるロールアウトの停止
失敗率のしきい値を設定して auto-pause を有効にします（500 basis points は 5% です）。失敗率がこの値を超えると、Capgo はロールアウトをロールバックします。実行中の新バージョンは Observe で確認できます。
Observe のドキュメントnpx @capgo/cli@latest channel set production \ --auto-pause-enabled \ --auto-pause-failure-rate-bps 500 \ --auto-pause-action rollback -
全員にプロモート
数値が想定どおりなら、bundle をチャネル内の全デバイスにプロモートします。そうでなければ、ロールアウトのコホートを stable に戻します。
ロールバックのドキュメントnpx @capgo/cli@latest channel set production --rollout-promote # or, if something looks wrong npx @capgo/cli@latest channel set production --rollout-rollback
プロダクションリリース向けに設計
ユーザーを驚かせることなく、頻繁にリリースを行うためのコントロールを提供します。
差分アップデート
--delta を使用して upload し、デバイスは現在の bundle から変更されたファイルのみを download します。変更の少ない大きなアセットは一度だけ download されます。
- 低速回線や従量制ネットワークのユーザーでも download 量を最小限に
- デフォルトモードでは、アップデートはセッション中ではなく、セッションの合間に適用されます
--delta
変更されたファイルのみを download
自動一時停止機能付きの段階的なロールアウト
他のユーザーが安定した bundle を使用している間に、特定のチャネルのランダムかつ固定された割合のユーザーにのみ新しい bundle を配信できます。CLI またはコンソールから、配信割合の引き上げ、昇格、またはロールバックが可能です。
- Auto-pauseは、失敗率がしきい値を超えた際にロールアウトを一時停止またはロールバックします
- Observeは、公開範囲を広げる前に新旧バージョンの比較を行います
1–5%
一般的な最初のロールアウトステップ
自動ロールバック
すべてのアップデートは正常に起動することを証明する必要があります。新しいbundleが制限時間内にnotifyAppReady()を呼び出さない場合、デバイスは最後に動作していたbundleに戻り、新しいbundleを失敗としてマークします。
- appReadyTimeout（デフォルトは10秒）以内にnotifyAppReady()が呼び出されない場合にロールバックが実行されます
- チャンネル全体を履歴内の任意の過去のbundleへロールバック
10秒
自動ロールバックまでのデフォルトのappReadyTimeout
ストア審査を考慮した配信
Capgo は、JavaScript、CSS、アセットなどの Capacitor Web レイヤーを配信します。ネイティブバイナリ、プラグイン、権限、エンタイトルメント、アプリストアのメタデータは変更しません。ストア審査はアプリごとに異なるため、ポリシーの遵守と承認の責任はお客様にあります。
- ネイティブ機能、プラグイン、権限、アプリストアのメタデータが変更される場合は、ストアへのネイティブリリースを使用してください
- レビュアー向けメモで、アプリの想定機能と Web レイヤーの更新経路を明確にしてください
- 提出のたびに、Apple と Google の最新ポリシーを確認してください
プロダクションチームの活用方法
ライブアップデート導入後の日常的なリリース作業。各カードはドキュメントにリンクしています。
Observeでリリース状況を把握
新しいbundleと以前のものを比較：エラー発生率、起動およびWebViewのタイミング、バージョンごとのデプロイマーカーを確認できます。
Observe のドキュメント通知による迅速なアップデート適用
チャネルのbundleを変更した後、サイレント通知を送信することで、デバイスが次にフォアグラウンドに移行するのを待たずに、即座にチェックを実行できます。
アップデート通知を送信古いNative Buildを保護
チャネルでメジャーアップデートをブロックすることで、新しいネイティブ code が必要なbundleが古いバイナリに配信されるのを防ぎます。
バージョン指定に関するドキュメントプロダクションアプリを支えるインフラ
Capgo は2021年からプロダクションアプリへのLive Updateを提供しています。
- 月間アップデート数
- 10億+
- 到達デバイス数
- 9,000万+
- Capgo 導入アプリ数
- 4,700+
- API の平均レイテンシ
- ~50ms
チームタイプ別ソリューション
チームのニーズに最適なソリューションを見つける
Capacitor で構築されたアプリ
高トラフィックなアプリには、本番環境での確実なUI変更が不可欠です
天気、公衆衛生、通信などのアプリは、正確なインターフェース、アラート、ナビゲーションに依存しています。本番環境でのアップデートを活用すれば、利用状況をモニタリングしながら、承認済みのUI修正を安全にリリースできます。
天気
医療
SUSに接続
ガイダンスやサービス情報の迅速かつ信頼性の高い更新が必要な公衆衛生アプリ。
- Google Play インストール数
- 27.7M
- ストア評価
- 4.6
ツール
Mi Orange
アラートやアカウント情報の表示が頻繁に更新される通信キャリア向けアプリ。
- Google Play インストール数
- 930万
- ストア評価
- 4.2
Sergiu S
リードデベロッパー、drivolino GmbH
“Capgo Capacitor Updater pluginのおかげで、アップデートの配信方法が完全に変わりました。以前は何日もかかっていた作業が、今ではわずか数分で終わります。”
Kapil
NuTriQ 創業者
“App Storeの審査サイクルを待たずに、本番環境へのOTAアップデートを即座に配信できることは、運用面で非常に大きなアドバンテージになっています。”
Michael Haberler
nethead emeritors
“Updater pluginは素晴らしい出来です。完璧に動作していますし、Live Updatesはテストのサイクルを劇的に速めてくれます。”
よくある質問
プロダクションチームからのよくある質問
アップデートがデバイスに届く仕組みや、問題が発生した際の対処法について。
ユーザーに live update が届くタイミングは？
デフォルトでは、アプリがフォアグラウンドに移行した際と、起動中に10分おきにアップデートを確認します。新しいbundleはバックグラウンドでダウンロードされ、ユーザーがアプリを離れた際にインストールされ、次回の起動時に反映されます。この挙動はautoUpdate設定で変更可能です。
アップデート動作のドキュメント
緊急の修正をより早くデバイスに反映できますか？
はい。チャンネルのbundleを変更した後、コンソールからアップデート通知を送信するか、bundle upload時に --send-update-notification を追加してください。デバイスにサイレントプッシュが届き、即座に確認が行われます。これには iOS および Android のプッシュ認証情報を用いた Capgo Notifications が必要です。配信はベストエフォート形式で行われます。オフライン状態や強制終了されたアプリは、次回の起動時に確認されます。
アップデート通知を送信
アップデートによってアプリがクラッシュした場合はどうなりますか？
新しいbundleが10秒以内（デフォルトのappReadyTimeout）に notifyAppReady() を呼び出さない場合、デバイスは最後に動作していたbundleに戻り、新しいbundleを失敗としてマークします。アプリの起動自体は妨げないバグについては、progressive rolloutをロールバックするか、チャンネル履歴から以前のbundleを選択してください。
ロールバックのドキュメント
一部のユーザーにのみ先行リリースするにはどうすればよいですか？
--rollout を使用して bundle をアップロードすれば、他のユーザーが stable 版を使用している間に、特定の割合のユーザーにのみ bundle を配信できます。配信割合の引き上げ、昇格、または CLI やコンソールからのロールバックも可能です。Auto-pause 機能を使えば、失敗率がしきい値を超えた際に自動で配信を停止できます。
段階的ロールアウトのドキュメント
live update で変更できないことは？
Live Update は JavaScript、HTML、CSS、およびアセットなどの Web レイヤーを置き換えます。Native plugin、Capacitor のアップグレード、capacitor.config の変更、および iOS や Android のプロジェクトファイルについては、ストア経由のリリースが必要です。Capgo はアップロード時に bundle のネイティブ互換性をチェックし、チャンネル設定によって古いバイナリへのアップデートをブロックすることも可能です。
ネイティブ互換性ドキュメント次の修正を live update としてリリースしましょう
トライアル期間中に、ご自身のアプリで一連の流れを試せます。bundle のアップロード、一部のデバイスへのロールアウト、そしてロールバックまで体験してください。