午後4時、Webレイヤーのアップデートが本番環境に反映されました。数分以内にクラッシュレポートが急増し、サポートチケットが届き始めます。調査の結果、新しい JavaScript bundle が一部のデバイスでのみ失敗していることが判明しました。App Store や Google Play の審査を待つ余裕はありませんが、設定、API、フィーチャーフラグ、または保存されたデータも変更されている場合、単に古いファイルを復元するだけでは不十分です。優れたロールバック計画には、何が対応のトリガーとなるか、どのバージョンを復元すべきか、復旧をどう検証するか、そして code のリバートが事態を悪化させる可能性はいつあるか、といった情報が含まれている必要があります。
以下の7つのプレイブックは、特定の障害タイプに応じたロールバックアクションをまとめたものです。 Capacitor および Electron アプリ、これには以下のチャネルを通じて配信されるリリースが含まれます： Capgo チャネル。これらをランブックのパターンとして活用し、例として挙げられているトリガーを、自社のクラッシュ、ビジネス、およびデータ整合性モニタリングの基準値に置き換えて使用してください。
目次
- 1. クラッシュ検知による自動ロールバック
- 2. バージョン履歴を用いた差分アップデートのロールバック
- 3. メトリクス悪化時に自動ロールバックする段階的リリース
- 4. Feature Flagsによる設定のみのロールバック
- 5. ユーザー同意と手動オーバーライドによるカナリアロールバック
- 6. スキーマバージョニングを用いたデータベースマイグレーションのロールバック
- 7. Observabilityとポストモーテムを活用したインシデントベースのロールバック
- 7つのロールバックプランの比較
- これらのロールバックプランをあなたのRunbookに活用しましょう
1. クラッシュ検知時の自動ロールバック
新しいWeb bundleが起動失敗、JavaScript例外、ネイティブプラグインの不具合、または前回リリースにはなかったクラッシュパターンを引き起こした場合、自動ロールバックが最初に取るべき対応です。トリガーはマシンリーダブルで、バージョン、チャネル、デバイスグループ、観測期間に紐づけるべきです。リリースコントローラーなら、エンジニアがダッシュボードに気づくのを待たずに配信を一時停止し、最後に正常動作していたbundleを復元できます。
Capacitor アプリでは、ネイティブクラッシュだけでなく、アプリが起動するか、WebViewが読み込まれるか、さらに notifyAppReady() 処理が完了するか、重要なプラグインが初期化されるか、最初のユーザーフローが成功するかを追跡してください。Electronチームは、レンダラープロセスの失敗、メインプロセスの例外、アップデートのインストール失敗、IPCコールの失敗も追加すべきです。
実践ルール: 自動ロールバックは、まずbundleへの露出を止め、その後でサービスを復元すべきです。ユーザーが疑わしいbundleを受け取っている間に根本原因を診断しようとしてはいけません。
実用的なトリガーは、リリースベースラインを上回るクラッシュやレディネスチェック失敗の持続的な増加などです。他のアプリの閾値をコピーしないでください。本番環境では保守的な制限を設定し、通常のデバイスやOSのばらつきに対して検証したうえで、単一のデバイスに反応しないよう十分な観測回数を確保してください。
トリガー、アクション、失敗モード
- トリガー: クラッシュ、起動、レディネス、ネイティブプラグインのシグナルが、対象チャネルのリリースゲートを超えた場合。
- アクション: チャネルの拡張を停止し、bundleをunhealthyとしてマークした後、以前の署名済みbundleを再デプロイし、起動と主要なフローを確認します。
- トレードオフ: 復旧は迅速ですが、トリガーの感度が高すぎると、無関係なデバイスやバックエンドの問題によって正常なリリースまでロールバックしてしまう可能性があります。
- 失敗パターン: 古いbundleが変更されたAPIや設定に依存している場合、アプリは起動しても後続の処理で失敗します。health gateに互換性チェックを含めてください。
デバイスごとの診断やクラッシュの相関分析を行うには、以下のガイドに従って、 Firebase CrashlyticsをCapacitorアプリに連携させてください。検知、チャネルの停止、再デプロイ、クライアントへのダウンロード、アクティベーション、そして旧バージョンが正常に動作することの確認まで、ステージングチャネルで一連のフローをテストしてください。
2. バージョン履歴を利用した差分アップデートのロールバック
差分ロールバックは、スタイルシート、アセット、設定値、またはJavaScriptモジュールに起因する問題に適しています。アップデーターは、現在のリリースと正常なターゲットとの間で差分があるファイルのみを転送するため、不安定な接続環境のユーザーのダウンロード負荷を軽減できます。なお、ターゲット側で完全なリリースを再構築できる必要があります。
トリガーとなるのは、Native Buildの変更を必要としない、ファイルレベルで確認された障害です。対応前に、アクティブなマニフェストと以前のマニフェストを比較し、Capacitor または Electron のランタイムバージョンを確認した上で、対象のチャンネルに互換性のある署名済みbundleがあることを確認してください。もし障害がその境界を超えている場合は、ファイルのみの修復を試みるのではなく、以前の完全なbundleをデプロイしてください。
差分配信は、部分的なリカバリではありません。 複数のリリースから任意のファイルを組み合わせてはいけません。不変（immutable）なマニフェストを保存し、チェックサムと署名を検証し、以前の完全なアーティファクトを保持した上で、チャンネル履歴にアクティブなバージョンを記録してください。JavaScript bundleとネイティブプラグインの不一致が発生すると、アプリの起動はできても、後続の重要なフローで失敗する可能性があります。
Capgo の アプリのバージョン履歴 を活用することで、運用担当者は再デプロイ前に正常なビルドを特定できます。各リリースについて、bundle識別子、ネイティブランタイムバージョン、Capgo チャンネル、設定のリビジョン、およびマイグレーションノートを記録してください。
以下のランブックを使用してください：
- 障害がWebアセット、設定、または code に限定されていることを確認します。
- 対象のチャンネルをフリーズし、他のデバイスに問題のあるバージョンが配信されないようにします。
- 単に直前のファイルを選ぶのではなく、最後に動作確認が取れた互換性のある署名済みbundleを選択します。
- クライアントとマニフェストの両方が安全な再構築をサポートしている場合にのみ、差分アップデートを生成します。
- 起動、整合性チェック、API との互換性、および影響を受けるユーザーフローをテストします。
- Capacitor および Electron クライアントでのダウンロード、アクティベーション、ロールバックの完了状況を監視します。
再構築の失敗、チェックサムの不一致、互換性のない Native Build 依存関係、またはアクティベーションループは失敗モードです。差分配信を停止し、保持されているフル bundle を再デプロイしてください。バージョン履歴は「何が変わったか」「どのリリースなら互換性の境界を安全に越えられるか」を明らかにしますが、テスト済みのロールバック用アーティファクトや移行ノートの代わりにはなりません。
3. メトリクスの低下に応じた自動ロールバックを伴う段階的ロールアウト
リリースが起動チェックを通過しても、コアとなるワークフローに悪影響を与える可能性があります。段階的ロールアウトでは、ベータ、ステージング、本番、または顧客コホートを別々の Capgo チャンネルに配置します。署名済み bundle は一度に1つずつ昇格させ、各チャンネルで以前の互換バージョンを利用可能な状態に保ちます。これにより、Capacitor および Electron クライアントへの影響を最小限に抑えつつ、直接的なリカバリパスを確保できます。
昇格前にリリースゲートを設定します。決済機能の変更であれば、クラッシュだけでなく決済完了数を監視してください。メッセージングなら、配信遅延や配信成功率を確認します。ヘルスケアの同期なら、レコードの完全性を検証します。各シグナルを、同じ対象者、デバイス構成、チャンネルのベースラインと比較してください。重要なアクションが正しく完了して初めて、リリースは「健全」であると言えます。
昇格時には以下の手順に従ってください：
- 技術的およびビジネス的なシグナルをレビューする担当者を割り当てます。
- 合意された期間、定義されたコホートを Observe します。
- 監視しているメトリクスが承認された閾値を超えた場合は、直ちに昇格を停止します。
- 影響を受けた Capgo チャネルを凍結し、リリースID、クライアントバージョン、設定、およびメトリクスの証拠を保存します。
- そのコホートに対して、最後に動作確認が取れた互換性のある bundle を再デプロイします。
- 代表的な Capacitor および Electron デバイスで、起動、アップデートの有効化、および影響を受けたワークフローを確認します。
- オーナーが復旧を確認した後にのみ、プロモーションを再開してください。
この Capacitor Live Updates の段階的ロールアウト・ガイド チャネルベースのリリースにおけるデプロイのコンテキストを提供します。自動ロールバックは、メトリクスと閾値が明確になった後にのみ実行されるべきです。ただし、決済、プライバシー、安全性、またはデータの整合性に関する問題が発生した場合は、統計的な確信が得られる前であっても、即座に対応が必要な場合があります。
主な失敗パターンは、ダッシュボードの監視範囲が狭いことです。ビジネス上の成果が悪化していても、技術的なヘルス状態は正常なままに見えることがあります。また、特定のデバイス、アカウント、またはネットワーク環境による稀なケースは、最初のコホートでは現れない可能性があります。次回のリリース前に、これらのギャップをランブックに記録しておいてください。
4. Feature Flags を使用した設定のみのロールバック
設定のロールバックは、特定の機能に限定された障害に適しています。新しい Capacitor または Electron の bundle をインストールしたまま、リモートフラグを使用して、影響を受ける Capgo チャネルまたはオーディエンスに対してリスクのあるパスをオフにします。これにより、無関係な code を置き換えることなく、レコメンデーションロジック、UIバリエーション、オプションの同期、実験的なストレージ、またはその他のガードされた動作をアプリ内で復元できます。
フォールバックは事前に用意しておく必要があります。現在のAPIやデータモデルとの互換性を確認し、オーナーを割り当て、リリース前にフラグのスコープと緊急時のデフォルト値を記録してください。インシデント発生後に古いパスを削除してフラグを追加しても、切り替える対象が残っていないため意味がありません。
フラグのロールバックを、範囲を限定したプレイブックとして実行する
- トリガー: 機能固有のエラー、ワークフローの失敗、プライバシーの問題、バッテリー消費、またはビジネス上の退行が、チームの合意した閾値を超えた場合。
- アクション: 対象となるCapgoのチャネルまたはオーディエンスに対してフラグを無効化します。クライアントに設定が反映されたことを確認した後、代表的なCapacitorおよびElectronデバイスでフォールバックをテストしてください。
- 確認事項: アクティブなフラグの状態、関連するイベント、起動時の挙動、および影響を受けたワークフローをチェックします。チームが原因を特定する間、新しいbundleはそのまま保持してください。
- トレードオフ: 変更は迅速かつ限定的ですが、共有依存関係、互換性のないネイティブcode、または破損したデータの修復はできません。
- 失敗パターン: アップデートが届かない、起動時に無視される、またはキャッシュが残る可能性があります。各関連イベントでフラグの状態をログに記録し、キャッシュの有効期限を定義しておいてください。
また、 フィーチャーフラグ実装ガイド Capgo のワークフロー内でこの制御を構成します。重要な機能については、ローカルに緊急用のデフォルト値を保持してください。設定の取得に失敗した場合は、アクセスを遮断（fail closed）するようにします。セキュリティやプライバシーに関わる機能は、コントロールプレーンの障害時にはアクセスを維持するのではなく、無効化すべきです。
5. ユーザーの同意と手動オーバーライドによるカナリア・ロールバック
カナリアリリースは、テレメトリ上では正常に見えても、特定のエンデプライズアカウント、ユーザーロール、またはインテグレーションにおいてのみ失敗している場合があります。そのグループに対して明確なフォールバック手段と、問題を報告する方法を提供してください。彼らのフィードバックは、集計メトリクスでは見落とされがちなワークフローやユーザビリティの欠陥を明らかにします。
ユーザー用とオペレーター用で制御を分けてください。ユーザー向けの操作は、問題が発生しているワークフローの外から利用可能にし、変更の差し戻し内容を説明した上で、現在のアクティブなbundle、native appのバージョン、Capgo チャンネル、デバイス、タイムスタンプを収集します。Capacitor アプリの場合は、以前のweb bundleがインストール済みのnative shellと互換性があるか検証してください。Electronの場合は、フォールバックがパッケージ化されたデスクトップランタイムと互換性を維持していることを確認してください。
リリース前にカナリアのトリガーを設定します：
- トリガー: 特定のセグメントからの継続的なオプトアウト、報告の集中、または技術的なメトリクスが合意された閾値を超えた場合に、チャンネルを凍結します。
- ユーザー操作： フォールバックの選択肢を表示し、同意と診断コンテキストを記録した後、ユーザーを以前の互換性のあるbundleに戻します。
- オペレーターの対応: 新規配信を停止してレポートを確認し、canaryチャンネルを安定版ビルドへリダイレクトします。コントロールプレーンやクライアントUIが利用できない場合に備え、手動でのオーバーライド手段を確保しておいてください。
- トレードオフ: 同意を得ることで透明性が向上し、問題を早期に発見できますが、バージョンが混在することでサポートコストが増大し、比較が複雑になります。
- 失敗パターン: ユーザーがコンテキストを送信せずにロールバックしたり、古いクライアントが変更後のバックエンドに対してエラーを起こしたりする可能性があります。OTAアップデートにおける ユーザーの同意に関するベストプラクティスを コミュニケーションおよびオプトアウト設計の一部として扱い、サーバーとの互換性を維持するか、対象機能を制御して無効化するようにしてください。
このロールバックをサーバー側の互換性問題の解決策として提示しないでください。バックエンドのコントラクトが変更された場合は、まず互換性を復元するか、影響を受けるワークフローを無効にしたままにしてください。
6. スキーマバージョニングを用いたデータベースマイグレーションのロールバック
bundleのロールバックでは、互換性のないスキーマを修復することはできません。CapacitorやElectronクライアントが以前のcodeに戻っても、APIやローカルデータベース側が新しいフィールドや変更された型、あるいはマイグレーション途中のデータを期待している場合、読み取りエラー、書き込み拒否、またはデータの不整合が発生する可能性があります。
移行作業は、リカバリパスを備えた独立したリリースとして扱います。まずは「拡張（expand）」フェーズから開始し、古いデータ構造を削除せずに、互換性のあるフィールドやテーブルを追加します。次に、新旧両方のフォーマットを読み書きできる code をデプロイし、バリデーションを行いながら既存レコードを移行します。トラフィックの切り替えは慎重に行ってください。レガシーな構造の削除は、以前のクライアントが不要になったことを確認してから行います。これにより、新しいスキーマをデプロイしたまま、Capgo チャネルのロールバックが可能になります。
「 ロールバック可能なデータベース移行 」のレビューでは、トランザクションを利用した移行、後方互換性のあるスキーマ、およびデータベースとアプリケーションの分離デプロイについて解説しています。これらの制御策を、決済記録、注文、患者情報など、安全に再作成できないデータに適用してください。
リリース前にリカバリパスを割り当てます：
- アプリケーションのロールバック： 現在のスキーマを読み取れることを確認した上で、以前の Capacitor bundle または Electron パッケージを復元します。
- 機能のロールバック： 互換性のあるスキーマ変更は維持したまま、新しい書き込みパスまたは機能フラグ（feature flag）を無効にします。
- 移行のリカバリ： 影響を受ける書き込みを停止してレコードを調査し、検証済みのフォワードフィックス（forward-fix）またはリカバリ手順を実行します。
- データの復元： code による切り戻しでデータの整合性が復元できない場合は、バックアップやポイントインタイムリカバリを使用してください。
フォワードおよびリカバリ用のスクリプトは常にレビュー可能な状態に保ってください。本番に近いデータでテストを行い、サポートされている場合はトランザクションやセーブポイントを活用しましょう。インシデント発生中に破壊的なロールバックSQLを生成してはいけません。アプリケーションの健全性、データの妥当性、書き込み互換性の成功条件を定義し、それぞれの判断を下す責任者を明確にしておきます。ステージング環境でリハーサルを行っていない移行計画は、信頼できるロールバックプランの例とは言えません。
7. 自動化されたObservabilityとポストモーテムによるインシデントベースのロールバック
Capgo チャネルではロールアウトが正常に見えていても、特定の Capacitor や Electron のコホートでリリース後に失敗が発生することがあります。リリース前に、継続的なクラッシュ信号、レディネスチェックの失敗、API フローの破損、確認されたデータ整合性エラーなど、インシデントのトリガーを定義しておきましょう。アラートが発生した際は、チャネルの拡張を停止し、実行中のbundle、Native Build のバージョン、チャネル、ロールアウト状態、影響を受けたコホート、エラーカテゴリ、タイムスタンプを記録します。デプロイ状態を変更する前に、これらの証拠をキャプチャしてください。
デプロイメントおよびリカバリメトリクスに関するDORAのガイダンス ロールバックを「変更の失敗シグナル」と「リカバリイベント」の両方として捉えます。リリース識別子とロールバックの結果を保存し、検知から復旧までの時間、影響を受けたセッションやデバイス数、復旧後のエラー率を比較します。これらの指標により、復元されたbundleによって障害が解消されたかどうかを確認できます。
インシデント対応を、記録可能な短いシーケンスとして実行します：
- トリガー: クラッシュ、準備状態、API、ビジネス、またはデータ信号に基づきアラートを確認します。
- 凍結（Freeze）： チャネルの拡張を停止し、フルロールバックよりも影響を抑えられる場合はフィーチャーフラグを無効にします。
- 保存（Preserve）： ログ、トレース、バージョン履歴、採用状況、および影響を受けたセグメントの詳細を保存します。
- ロールバック（Rollback）： Capacitor または Electron 用の最後に互換性があった bundle を再デプロイし、Native Build の互換性も考慮します。
- 確認（Check）： 起動とクリティカルなフローをテストし、エラー信号が減少していることを確認します。
- レビュー（Review）： 原因、検知漏れ、決定事項、およびランブックの変更内容を記録します。
ロールバックの失敗自体がトリガーとなります。復元したバージョンがクラッシュする場合や、起動できない、あるいは同じ API の失敗が再現する場合は、以前の正常なチャネルや手動デプロイへの切り替えを検討してください。これには Forge Reliability の根本原因分析ガイド を使用して調査を構造化します。証拠が残っているうちに責めないポストモーテム（Blameless Post-mortem）を実施し、各是正措置に担当者を割り当て、結果として得られたレディネスチェックやチャネルのガードレールをリハーサルしてください。
ロールバックプランの事例比較 7選
| 戦略 | 実装の複雑さ 🔄 | 必要なリソース 💡 | 期待される成果 📊 / ⭐ | 最適なユースケース 💡 | 主なメリット ⭐ / ⚡ |
|---|---|---|---|---|---|
| クラッシュ検知時の自動ロールバック | 中程度 🔄🔄 | リアルタイム監視 + エラー追跡システム | 迅速な緩和; MTTRの低減 📊 ⭐⭐⭐⭐ | 高い安定性が求められるプロダクションアプリ (金融, ヘルスケア) | サイレントな自動保護; 高速な復旧 ⚡ ⭐ |
| バージョン履歴による差分アップデートのロールバック | 高 🔄🔄🔄 | バージョン保存, 差分エンジン, ステート管理 | 帯域幅効率が高く、正確なロールバック 📊 ⭐⭐⭐⭐ | ネットワーク環境の悪いユーザー, 大容量アセット, インディーチーム | ファイル単位の精度; ロールバックのダウンロード容量を大幅削減 ⚡ ⭐ |
| メトリクス悪化時に自動ロールバックする段階的リリース | 極めて高い 🔄🔄🔄🔄 | 堅牢なメトリクス基盤、A/Bテスト、ターゲティング | 影響範囲を最小化し、ビジネス指標を保護 📊 ⭐⭐⭐⭐ | Eコマース、収益に直結する機能、大規模ユーザー層 | データに基づく段階的リリース。ビジネスへの影響を早期検知 ⭐ 📊 |
| Feature Flagsによる設定のみのロールバック | 低い 🔄 | Feature flagging/設定デプロイ（再ビルド不要） | 機能の即時ロールバック。ユーザーへの影響を最小限に 📊 ⭐⭐⭐ | 機能のデグレード、迅速な修正、小規模チーム | 最速のロールバック（数分以内）。ストア審査不要 ⚡ ⭐ |
| ユーザー同意と手動オーバーライドを伴うCanary Rollback | 高 🔄🔄🔄 | Canary ターゲティング、アプリ内 UI、フィードバック収集 | エッジケースの早期検知、定性的なインサイト 📊 ⭐⭐⭐ | エンタープライズ向けベータプログラム、ユーザーフィードバック主導のリリース | ユーザーによる制御 ＋ 直接的なフィードバック、より安全な早期テスト ⭐ 💡 |
| スキーマバージョニングによるデータベース移行のロールバック | 非常に高い 🔄🔄🔄🔄 | DB の専門知識、移行ツール、ステージングデータ | データの整合性を維持、コンプライアンスに準拠したロールバック 📊 ⭐⭐⭐⭐ | 規制業界、eコマース、複雑なデータを扱うアプリ | 安全な双方向移行、監査トレイルとバリデーション ⭐ |
| オブザーバビリティとポストモーテムを活用したインシデントベースのロールバック | 極めて高い 🔄🔄🔄🔄 | 高度なオブザーバビリティ、インシデント管理、ストレージ | フォレンジック情報に基づく迅速な対応と組織的な学習 📊 ⭐⭐⭐⭐ | 信頼性とSREプラクティスを重視する大規模サービス | 自動ロールバック + 非難のないポストモーテムのための完全なフォレンジックデータ ⭐ 📊 |
これらのロールバック計画例をランブックに活用しましょう
すべてのインシデントに対して単一のロールバック手法を選ぶべきではありません。まずは最も影響範囲の狭い安全なアクションから開始してください。データの整合性を保ちつつ、機能フラグで問題のパスを無効化できるなら、それを優先します。リリース自体が不安定な場合は、チャネルの拡大を停止し、自動クラッシュ検知やレディネスゲートを備えたステージドチャネル制御を使用してください。失敗が共有のcode、設定、または互換性のないAPIに影響を与える場合は、最後に動作した互換性のあるbundleをリストアし、ユーザーフロー全体を検証してください。
最も困難な判断はデータに関するものです。bundleのロールバックは、スキーママイグレーション、部分的な書き込み、またはサーバー側の挙動変更を元に戻すものではありません。それらのインシデントでは、リスクのある書き込みを凍結し、データオーナーを関与させ、以前のクライアントが自動的に安全であると決めつけずに、マイグレーションセーフな手順に従ってください。2012年のKnight Capitalの失敗は、なぜ以前のバイナリをリストアするだけでは不十分なのかを示しています。サーバーに休止状態のレガシー機能が残っており、再利用されたフラグがそれを起動させ、ロールバックの試みが環境全体で問題の挙動を有効なままにしてしまったのです。このインシデントでは、およそ 3億9700万件の誤った株式取引が実行され、想定ポジションは約 70億ドルに達し、当初報告された税引前損失額は約 4億4,000万ドル、後に〜の近くに配置された 4億6,000万ドル 広範な報道では、こちらの Knight Capitalのロールバック失敗に関する記録に記載されている通り、.
SpotifyのStormデプロイメントは、ステートフルなシステムにおけるもう一つの有用な原則を示しています。2つの完全なトポロジーバージョンを保持し、コンシューマーの位置を維持し、可逆的なアクティベーションを使用することで、ストリームを失うことなく以前のバージョンを復元できます。これは SpotifyのApache Stormデプロイメントに関する記録に詳述されています。同様の Capgo 設計では、以前の署名済みbundleを保持し、バージョン固有のヘルスゲートを維持し、古いリリースを削除する前に互換性を確認します。
これらの考え方を簡潔な決定ツリーにまとめると以下の通りです：
- 機能固有の障害： フィーチャーフラグを無効化し、フォールバックを確認して、原因を調査する。
- リリースの不安定性： チャンネルを凍結し、最後に互換性があったbundleを再デプロイして、復旧状況を監視します。
- セグメント特有の不確実性: プロモーションを停止し、カナリアリリースによるフィードバックと手動オーバーライドを活用します。
- スキーマまたはデータの不整合リスク: code を盲目的にロールバックしないでください。変更を凍結し、マイグレーションまたはデータ復旧プランを実行します。
- 原因が不明な場合: まず証拠をキャプチャして影響範囲を抑え込み、その後、最も影響が少なく、かつ元に戻せるアクションを選択します。
今日、一つのプレイブックを選んでください。トリガー、担当者、正確なロールバックコマンドまたはダッシュボードでの操作、検証手順、およびエスカレーションパスを明文化します。次の本番リリース前に、アップデートの失敗、レディネス信号の異常、設定の差し戻し、互換性チェックなどを含め、ステージングチャンネルで実行しておきましょう。ロールバックが「事後に書かれた文章」ではなく「訓練されたオペレーション」になっていれば、チームの復旧速度は劇的に向上します。
Capgo は、CapacitorJS および Electron アプリ向けに、ターゲット指定可能なチャンネル、バージョン履歴、デバイスごとのログ、採用率と失敗のメトリクス、差分配信、および自動ロールバック保護を備えた、署名付きのLive Updateを提供します。 Capgo を使用して、アプリに最適なロールバックプランの例を、テスト済みのリリースおよび復旧ワークフローへと昇華させましょう。
