モバイルアップデートは、問題が発生する前にユーザーに影響を与える可能性があります。アプリストアのリリースは、ウェブデプロイと同様に取り消すことができません。正しいロールバック設定は、安全なパスを提供します: 小さな変更を配信し、ライブ信号を監視し、1 つのコマンドで知られている良好なバンドルを復元します。このガイドでは、評価と実行プロセスを評価して実行する方法を示します。 Capgo.
目次
- Capgo
- 機能比較
- プラットフォームへの接続
- リリースのステージング
- 自動ロールバックの設定
- ロールバックプラットフォームの運用
- FAQ
- まとめ
1. Capgo
Capgoは、IonicおよびCapacitorアプリ向けのOTA更新とロールバックプラットフォームです。ウェブ層の変更を新しいストアのレビューの待たずに配信し、チャンネルやステージドリリースを通じてどのバンドルが受け取るかを制御できます。
Capacitorの重要な点は、合うことです。Capacitorアプリには、ネイティブシェルとWeb層があります。 OTA更新 Capgoは、Web層を変更できる一方で、ネイティブの変更はiOSまたはAndroidの新しいビルドが必要です。Capgoは、この分割を中心に構築されているので、各種類の変更に対して正しい方法でリリース計画を管理できます。
Capgoは、以下の4つの要素を同じワークフローに統合します。
- 自動ロールバック: アプリは、リリースが正常性チェックを通過しない場合に、安定したバンドルに戻ることができます。
- 差分更新: ユーザーは、バンドルの変更部分のみをダウンロードすることで、帯域幅の使用を削減できます。
- CI/CD統合: チームは、GitHubアクション、GitLab CI、またはJenkinsとリリースを接続できます。
- リアルタイム分析: リリースチームは、バンドルの拡散に伴ってアプリの採用と健康状態をリアルタイムで監視できます。
弱いモバイル接続では、バンドルサイズが大きいとダウンロードが遅くなる可能性があります。小さなパッチでは、ダウンロードサイズが小さく、緊急修正がユーザーに迅速に到達する可能性が高くなります。
Capgo also uses one-command deployment. In practice, that means a build job can publish a tested bundle without a developer opening a dashboard and repeating release steps by hand. Keep the command in your pipeline. Review the output. Then let your channel rules control exposure.
ロールアウト前に、明確な安定版を設定し、リリースIDを設定し、関連するコミット、ビルドノート、テスト結果を保存してください。2時ごろに回復する必要がある場合、安全なバンドルを推測する必要がなくなるでしょう。
Security needs the same care. Review Capgo’s オーバー・ザ・エア更新の信頼情報 を確認する前に、セキュリティ設定を確認してください。その後、チームメンバーがプロダクションチャンネルを公開、停止、またはロールバックできるように設定してください。
For teams that need a preview before production, a pull request can map to its own channel. That keeps a tester’s bundle away from the main release path. Capgo’s プルリクエストプレビューチャンネル 機能は、このようなレビューフローをサポートできます。
Capgoは、CapacitorまたはIonicを使用するアプリの強力なスターティングポイントです。ロールバック、小さいアップデートパッケージ、CI/CD、分析を1つのサブスクリプションあたり組織ごとに提供します。権限の変更、ネイティブプラグイン、またはアプリシェルを変更した場合、ネイティブストアのリリースを置き換えることはできません。その境界は、最初の日からリリースポリシーに含めるべきです。
Step 2: Capabilityによるロールバックプラットフォームの比較
ロールバックプラットフォームを評価するには、機能リストだけではありません。回復パスを比較してください。ユーザーに不良のバンドルが到達した場合に何が起こるか、デバイスがダウンロードするデータの量、パイプラインがマニュアル作業なしで公開できるかを尋ねてください。
以下の表は、上記の質問を使用しています。
| オプション | ロールバックパス | 差分アップデート | CI/CD統合 | 適切なフィット |
|---|---|---|---|---|
| Capgo | コンテキスト:Capgo UIのHTMLテキストフラグメント(親キー`submitting_a_pr_to_capgo`。ページ/エリア:Capgoマーケティングウェブサイト。ロール:ウェブサイトコピー文。見られる場所:contributing.astroページ。 | 自動および手動ロールバック | GitHub アクション、GitLab CI、Jenkins | Capacitor と Ionic チームが 1 つのリリースフローを望む |
| Appflow | 前のバージョンは即時復元できます | いいえ | — | 既存のユーザーがマイグレーションを計画している |
| Expo の更新 | 手動で以前のチャネル更新に戻す | いいえ | ネイティブ統合のみ | Expo と React Native プロジェクト |
| Shorebird | 元のパッチまたはオリジナルのバイナリに戻す | はい | — | フラッターのチーム |
| CodePush | クラッシュベースの自動ロールバック(一定期間内) | いいえ | ネイティブ統合のみ | コミュニティ CodePush の展開を管理しているチーム |
| EAS Update | 前のチャンネルにロールバック | いいえ | ネイティブ統合のみ | React NativeチームはEASをすでに使用しています。 |
| 手動の更新 | 新しいストアのレビューが必要です。 | いいえ | — | OTAレイヤーなしのアプリ |
スタックフィットは最初です。Expo UpdatesとEAS UpdateはReact Nativeの議論に属します。ShorebirdはFlutterの議論に属します。Capacitorチームは、ロールバック言語が馴染みのあるツールを選択しないようにしてください。実行時は、ツールが安全に変更できることを決定します。
次に、更新サイズを確認してください。研究では、Shorebirdのパッチが約50から200KBで、フルFlutterのリリースが約15から30MBであることを比較しています。その差はモバイルデータユーザーにとって大きいです。Capgoは、Capacitorアプリのウェブ層の更新に対して、差分配布を適用します。
分析も別の区別線です。ロールバックボタンは行動を教えてくれます。ライブ分析は行動のタイミングを教えてくれます。リリースレベルデータがなければ、チームはサポートチケットの待ち合わせを待つことになります。その遅延は小さな問題をより広範なインシデントに変えます。
ExpoはCI/CDワークフローとパフォーマンスメトリクスを、Observeサービスを通じてサポートしています。比較はランタイムに従うべきであり、一般的なスコアに従うべきではありません。
コストもより広い視点が必要です。低いエントリ価格は、別の分析ツール、カスタムロールバックスクリプト、ストレージ、警告、エンジニアリング時間を追加した場合に、良いように見えます。Capgoは、組織ごとにサブスクリプションを使用し、14日間の無料試用期間を提供しているため、リリースフローをテストすることができます。
One more check: vendor direction changeを確認する。新規プランを販売しなくなったプラットフォームは、現在のユーザーには機能するが、将来の移行タスクを生み出す。ベンダー状況と技術能力を評価シートに並べる。
Key Takeaway: Step 3: プラットフォームをビルドとCI/CD Pipelinesに接続する
A rollback plan only works when your release pipeline can publish the known-good bundle again. Connect the mobile app rollback platform to source control, tests, and deployment commands before your first incident. For practical rollback strategies for CI/CD workflows
, map each pipeline failure to a clear stop, pause, or restore action. Start by separating native builds from web-layer releases. A native build changes the app binary. An OTA bundle changes __CAPGO_KEEP_0__ that the installed binary can already run. Write this rule into your pipeline so a native dependency never slips into an OTA release by mistake.Then set up a release job with a small number of fixed stages:
Start by separating native builds from web-layer releases. A native build changes the app binary. An OTA bundle changes code that the installed binary can already run. Write this rule into your pipeline so a native dependency never slips into an OTA release by mistake.
Run type checks and unit tests.
- Build the web assets.
- Step 2: Pick the platform that matches your runtime and gives your team a tested recovery path, not the platform with the longest feature list.
- Step 1: Ask what happens when the vendor changes direction. A platform that no longer sells new plans may still work for current users, but it creates a future migration task. Put vendor status beside technical capability in your review sheet.
- アプリのSmokeテストを実行してください。
- 非生産チャンネルにバンドルを公開してください。
- テストしたバンドルを生産に昇格してください。
デプロイ用トークンに保護されたシークレットを使用してください。トークンはリポジトリに保存してください。ジョブログに表示してください。生産ジョブに別の承認ルールを付与してください。チームが人間のチェックを必要とする場合にのみ、公開前にジョブを承認する必要があります。
CapgoはGitHubアクション、GitLab CI、Jenkinsと接続されています。ランナーは具体的には関係ありません。リリース契約が重要です。ジョブは、どのコミットをビルドしたか、どのチャンネルをターゲットにしているか、どのバージョンを置き換えることができるかを知る必要があります。
新しいプロジェクトの場合、最初のパイプラインは単純に実行してください。リリース候補ごとに実行してください。テストチャンネルにバンドルを公開してください。アプリがバンドルをダウンロードし、クリーンに起動し、稼働準備を報告することを確認してください。ジョブがリリースを昇格するのは、確認が終わった後のみです。
Capacitorチームは、lintとテスト用に一般的なCIランナーを使用し、次にネイティブビルドをモバイルに特化したサービスに移行することがよくあります。この分離は効果的です。Pullリクエストごとに高速チェックを近づけ、署名とストアビルドをモバイルに特化したシステムに残すことができます。
Capacitor CI/CDの研究では、一般ランナーとモバイルスペシャリストの重要な違いが見つかりました。一般ランナーはコントロールが高くなりますが、パイプラインを自分で書く必要があります。専門サービスは、署名、ネイティブビルド、ライブアップデートを同じワークフローで管理する必要がある場合にセットアップワークを削減できます。チームが選択を検討している場合にのみ、 リリースガイドを参照してください。 承認ルール
今すぐ失敗パスをテストする。Smokeテストを破壊し、パブリッシュステップが止まることを確認する。非生産プロジェクトに間違ったチャンネルにバンドルを送信し、生産が触れられないことを確認する。これらのチェックは、実際のインシデントがパイプラインに圧力を加えるまで、小さく感じる。
この時点で、テストされたバンドルを1つ発行し、前の安定バンドルを特定し、チェックが失敗したときに安全に停止できるジョブが繰り返し実行できるはずです。それがステージドロールアウトの基盤です。
ステップ 4: チャンネル、ロールアウト、分析を使用したリリースのステージング
チャンネルは、各アウディエンスに制御されたリリースパスを提供します。これらは、バンドルがすべてのユーザーに到達する前に、モバイルアプリロールバックプラットフォームが損害を制限する主な理由です。
少なくとも3つのチャンネルを設定する。
- プレビュー: 開発者と製品テスターが使用します。
- カニ: 小さなグループの実ユーザーまたはデバイスを使用します。
- 生産: ソーク期間後、フルアウディエンスが使用します。
チャンネルルールを明確に保ちます。プレビューのバンドルは自分自身を昇格させない。カニリリースには名前の付いたオーナーが必要です。生産には、インシデントチームの誰でも理解できるポーズルールが必要です。
ユーザー ベースを反映したキャニラーグループを選択してください。最新の携帯電話だけを含めないでください。デバイスの年齢、OS バージョン、ネットワークの品質、使用パターンは、すべてバンドルの動作を変える可能性があります。
小規模なロールアウトは、被害の範囲を縮小します。10人のユーザーが不良のバンドルを受け取った場合、チームは調査する余裕があります。すべてのユーザーが一度に受け取った場合、サポートキューは監視システムになります。そのような場所でリリースについて学ぶことは、悪いことです。
ユーザーへの被害につながる信号を監視してください。クラッシュ数だけでは、キャニラーグループが活発であるため、上昇する可能性があります。クラッシュしないユーザー、失敗した起動、認証エラー、重要なアクションの完了を組み合わせてください。リリース前に基準を設定してください。チームは何が変化したかを知ることができます。
信号が合意した限値を超えた場合に停止してください。完璧な診断を待つ必要はありません。最初の行動は、抑制です。チャネルをロールバックするか、プロモーションを停止してください。次に、ログを検査し、失敗したリリースと最後の安定したコミットを比較してください。
OTAには制限があります。ネイティブプラグインを追加することはできません。パーミッションを変更することはできません。ネイティブ依存関係を置き換えることはできません。主な機能をプッシュすることもできません。ストアレビューが必要な変更は、ストアリリースを使用してください。その後、インストール済みバイナリに合うウェブ層の修正は、OTAを使用してください。
エンタープライズアプリでは、デバイスグループを追加してください。倉庫デバイスとオフィス電話のロールアウトペースは異なる可能性があります。フィールドチームは不完全な接続を使用する可能性があります。そのようなグループは、1つのテストプールとして扱うべきではありません。
Capgoのチャンネルモデルは、このような分離をサポートしています。追跡、採用、ロールバック。短いループは、リリースオーナーが各バンドルの保持するチャンネルを確認できる場合に、実行しやすくなります。
リリースノートを各プロモーションとともに保存してください。変更の理由、ユーザーへの期待される効果、次のステージに進むための信号を記録してください。そのノートは、ユーザーが何が変わったかと尋ねたときに、サポートチームと製品チームが共有する答えを提供します。
プロのアドバイス: プロモーション許可よりも、停止許可を広く設定してください。サポートリーダーは、元の開発者を待たずにリスクのあるロールアウトを停止できるようにしてください。
ステップ 5: 自動ロールバックの設定とテスト
自動ロールバックは、健康信号を回復アクションに変えることができます。安全に使用するには、リリース前日に定義する必要があります。信号、タイムウィンドウ、安定バージョン。詳細な Capacitorの更新ロールバック設定 も、チームがステージングテストにルールを接続するのを助けてくれます。
最初に、知られている良いバンドルから始めましょう。Smokeテストと短いプロダクションソークを通過した後、安定したものとみなします。リリースIDをデプロイメントレコードに保存してください。ロールバックシステムは、フォールバック自体がテストされていない場合に無駄です。
次に、行動を起こすべきエラーを選択してください。良い候補は次のとおりです。
- インストール後にアプリがクラッシュする急激な増加。
- アプリ起動中に繰り返し失敗。
- A login またはデータの読み込みパスが破損している。
- A重要なユーザーアクションの数値が大幅に下がっている。
- インテグリティまたはバンドルの検証が失敗している。
インストール後に一定の時間枠を設定する。最初の起動時にバグが発生するものもあるが、特定の画面に到達するまでバグが現れるものもある。重要なパスをカバーする時間枠を設定する必要がある。
次に、システムの動作を決定する。プロモーションを一時停止するか、影響を受けたチャネルを最後の安定バンドルに戻すか、または両方のアクションを実行する必要がある。順序を書き留め、安全なチャネルで意図的に不正なリリースをテストする。
Mobile rollback is different from a web revert. A store binary already installed on a phone cannot simply vanish. A new native fix may need store review. OTA rollback works within the code that the installed native shell can run.
ロールバックは機能フラグと良好なリリーステストと並んで置かれるべきである。機能がオン/オフにできる場合は、バンドルを置き換えることなく機能を切り替えることができる場合は、リバートする必要がなくなる。
少なくとも3つのドリルを実行する。
- リードネスチェックで失敗するバンドルを公開する。
- インストール後に制御されたエラーをトリガーする。
- 安定バンドルに戻り、リードネスを報告することを確認する。
各ドリルをタイムする。問題を検出するのにかかる時間、露出を一時停止するのにかかる時間、安定バンドルに戻り、回復を確認するのにかかる時間を測定する。数値はチームに有益なインシデント目標を与える。
自動化は短いネットワークのダウンタイムをアプリの失敗と誤読することがある。リリースの所有者は自動アクションを一時停止し、信号を検査し、安全な場合に前方の修正を選択できるようにする必要がある。
For detailed Capacitor rollback steps, the guide on Capgoのロールバック管理のガイド はバンドル選択、更新アプリケーション、リードネスチェック、ステージドテストをカバーしています。
自動ロールバックを使用して迅速な収容を行うが、レビューをスキップする許可を与えるものではない。最も安全なシステムは早期に悪いリリースを捕捉し、エンジニアに根本原因を修正するための明確な方法を提供する。
Step 6: Launch後Rollback Platformの運用
モバイルアプリロールバックプラットフォームには、リリース後も運用ルーチンが必要です。誰かがリリースを監視し、停止するか、ロールバックするか、ロールフォワードするかを決定し、回復パスを準備する必要があります。
最初のプロダクションロールアウト前に、明確な役割を割り当ててください:
- リリースオーナー: バンドルをプロモートし、変更を記録する。
- インシデントオーナー: 停止、ロールバック、またはロールフォワードするかを決定する。
- サポート担当者: ユーザーからの報告を監視し、共通の症状を共有する。
- エンジニアリング担当者: 問題を追跡し、修正を準備する。
リリース後、一定のポイントでダッシュボードを確認する。初期採用を確認し、次にクラッシュ、起動時間、失敗したリクエスト、主なユーザーアクションを検査する。10分後に問題が見えなくても、ユーザーがよりまれなフローに到達すると問題が発生する可能性がある。
大規模な艦隊向けにはリングベースのロールアウトを使用する。最初のリングには、さまざまなデバイスモデルとネットワーク条件を含める。開発者が新しい電話のみで埋めないようにし、古いハードウェアやストレージが限られているユーザーが直面する問題を表示しないようにする。
エンタープライズ展開の場合、チャンネルをリスクにマップする。配達や決済用のデバイスには、内部ニュース用のデバイスよりも厳密なゲートが必要である。リカバリデバイスをロールアウトグループから外すと、オペレーターはインシデント中でも管理ツールにアクセスできる。
リリース管理の一部はコミュニケーションである。サポートに変更を伝え、リリースIDと症状を提供する。ロールアウトを停止した場合、次のチェック時間を説明する。クリアなメモは重複した報告を減らし、ストレスの下でランダムな変更をしないようにする。
インシデント後、すべてのロールバックをレビューする。問題を捕捉したもの、見逃したもの、トリガーが早かったかを尋ねる。次に、テストケースまたは閾値を更新する。ロールバックは、最初に障害の際に有効であり、次にリリースの証拠として有効である。
古いバンドルの保持期間は、ポリシーが必要な期間に合わせてください。バージョンが多すぎると選択が難しくなり、バージョンが少なすぎるとフォールバックが失われます。保持期間のルールを設定し、安定したリリースを新しいチームメンバーが理解できるようにラベル付けしてください。
アクセス制御も重要です。生産環境の公開を制限し、高リスクの変更には2回目のレビューを必要とします。バンドルのプロモーションやリバートの記録を保管し、Capgo チームもリリースデータの取り扱いについてのドキュメントを書く際にデータポリシーを参照できます。 Capgo データポリシー 実際のインシデントの際にプロセスが明確であることを確認するために、回復ドリルを計画してください。テストチャンネルと無害なエラーを使用し、リリースを作成しない人にロールバックの手順を実行させます。ロールバックと安定したバンドルの切り替えが可能であれば、プロセスは十分に明確です。
目標は、安全な変更の場合に速く、信号が不明な場合に慎重に、ルールがわかっている場合に自動化するリリースです。
FAQ
__CAPGO_KEEP_0__ は、__CAPGO_KEEP_1__ と Ionic チームが OTA 更新とロールバック制御が必要な場合に最適なフィットです。自動ロールバック、差分更新のサポート、CI/CD統合、リアルタイム分析を含む、組織ごとのサブスクリプションで提供されます。また、14日間の無料試用版も提供されているため、チームはリリースパスを生産環境で使用する前にテストできます。
Capacitor は実際にロールバックできるのですか?
Capgo is a strong fit for Capacitor and Ionic teams that need OTA updates with rollback control. It combines automatic rollback, differential update support, CI/CD integration, and real-time analytics under a subscription per organization. It also includes a 14-day free trial, so your team can test the release path before using it in production.
__CAPGO_KEEP_1__
モバイルアプリは、OTA Web層のバンドルを巻き戻すことができますが、すでにアプリストアからインストールされているネイティブバイナリを消去することはできません。巻き戻しは、インストール済みのネイティブシェルが以前のバンドルを実行できる場合にのみ機能します。ネイティブプラグイン、権限、依存関係の変更は、すべて新しいストアリリースが必要です。
自動巻き戻しはどうやって動作するのですか?
自動巻き戻しは、バンドルがインストールされた後、ヘルスシグナルを監視します。リリースがセットされた失敗ルールを超えると、システムはプロモーションを停止し、影響を受けたチャンネルを安定したバンドルに戻します。短いネットワーク問題から生じた誤ったトリガーは、無駄な回復作業を引き起こす可能性があります。安全なチャンネルでトリガーをテストしてください。
OTA更新後、どの指標を監視するべきですか?
クラッシュフリーのユーザー、失敗した起動、ログインエラー、データロードの失敗、主なアクションを監視してください。各シグナルをリリース前のベースラインと比較してください。突然の低下は、raw数がまだ小さく見える場合でも重要です。カニチャンネルを監視して、ロールアウトを拡大する前に。
App Storeレビューは置き換えられますか?
App Storeレビューはネイティブの変更や主なアプリ機能の場合にのみ置き換えられます。インストール済みのネイティブシェル内で更新可能なWeb層のcodeを更新できます。権限、ネイティブモジュール、ネイティブ設定の変更の場合は、ストアリリースを使用してください。CI/CDルールにその境界を維持してください。
まとめ
Capgoを選択する際は、CapacitorまたはIonicチームが1つのリリースパスを必要とする場合にのみ 差分更新、チャンネル、分析、CI/CD、およびロールバック。14日間の無料試用版を開始し、テストプロジェクトに接続し、1回のステージリリースを実行して、生産トラフィックを移動する。小さなドリルは、チームがトラッキング、採用、停止、ロールバックを行うことなく、推測をせずに実行できるかどうかを示すだろう。
