モバイルアプリロールバックプラットフォーム:ハウツー

モバイルアプリの更新が不正確な場合、ユーザーに影響を与える前に、チームが問題が存在することを知るまでに時間がかかります。アプリストアのリリースは、ウェブデプロイと同様に取り消すことができません。正しいロールバック設定は、安全なパスを提供します: 小さな変更を送信し、ライブ信号を監視し、1 つのコマンドで知られている良いバンドルを復元します。このガイドでは、評価と実行プロセスを評価して実行する方法を示します。 Capgo.

目次

• Capgo
• ステップ 2: 回転プラットフォームの機能を比較する
• ステップ 3: プラットフォームをビルドと CI/CD Pipelines に接続する
• ステップ 4: チャンネル、ロールアウト、分析を使用したリリースのステージング
• ステップ 5: 自動ロールバックを構成してテストする
• ステップ 6: ロールバックプラットフォームをリリース後に運用する
• FAQ
• 結論

1. Capgo

Capgo は、Ionic と Capacitor アプリ向けの OTA 更新とロールバックプラットフォームです。ウェブ層の変更を新しいストアのレビューを待たずに配信し、チャンネルとステージド リリースを使用して、各パッケージを受け取るユーザーを制御できます。

主なポイントは、フィットです。Capacitor アプリには、ネイティブシェルとウェブ層があります。 OTA更新 Capgoは、ウェブ層を変更できる一方、ネイティブの変更は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を付与し、関連するコミット、ビルドノート、テスト結果をその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によるロールバックプラットフォームの比較

ロールバックプラットフォームを評価するには、機能リストだけではありません。回復パスを比較してください。悪いバンドルがユーザーに到達した場合に何が起こるか、デバイスがダウンロードするデータの量、パイプラインがマニュアル作業なしで公開できるかを尋ねてください。

以下の表は、上記の質問を使用しています。

スタックフィットは最初です。Expo UpdatesとEAS UpdateはReact Nativeの議論に属します。ShorebirdはFlutterの議論に属します。Capacitorチームは、ロールバック言語が親しみやすいツールを選択しないようにしてください。実行時は、ツールが安全に変更できるかどうかを決定します。

次に、更新サイズを確認してください。研究では、Shorebirdのパッチが約50から200KBで、フルFlutterのリリースが約15から30MBと比較されています。これは、モバイルデータユーザーにとって大きな差です。Capgoは、Capacitorアプリのウェブ層の更新に対して、差分配布を適用します。

分析も別の区別線です。ロールバックボタンは、どのように行動するかを教えてくれます。ライブ分析は、いつ行動するかを教えてくれます。リリースレベルデータがなければ、チームはサポートチケットを待つことになります。その遅延は、小さな問題を広範囲のインシデントに変えます。

ExpoはCI/CDワークフローとパフォーマンスメトリックを、Observeサービスを通じてサポートしています。比較は、ランタイムに従って行うべきです。一般的なスコアに従うのではなく。

コストもより広い視点が必要です。低いエントリ価格は、別の分析ツール、カスタムロールバックスクリプト、ストレージ、警告、エンジニアリング時間を追加した場合に、良いように見えます。Capgoは、組織ごとにサブスクリプションを使用し、14日間の無料試用期間を提供しているため、リリースフローをテストすることができます。

一時的な確認: 供給元が方向性を変える場合に何が起こるかを確認する。新規契約を販売しなくなったプラットフォームは、現在のユーザーには機能するかもしれないが、将来の移行タスクを生み出す。 (Translated naturally for the user cultural context, adapting idioms, grammar, tone, and phrasing instead of translating word for word. Preserved brand names, product names, developer terms, URLs, code identifiers, file paths, package names, language codes, numbers, punctuation, and whitespace meaning.)

Key Takeaway: ランタイムに合ったプラットフォームを選び、チームにテスト済みの復旧パスを提供するのではなく、最長の機能リストを持つプラットフォームを選ばないでください。

Step 3: CapgoプラットフォームをビルドとCI/CDパイプラインに接続する

リリースパイプラインが再び知られている良い状態のバンドルを公開できる場合にのみ、ロールバック計画が機能します。モバイルアプリケーションロールバックプラットフォームをソース管理、テスト、デプロイコマンドと接続する必要があります。最初のインシデント前に実行してください。実際には、ロールバックの準備が整っていることを確認するために、定期的なテストとデプロイを実行する必要があります。 CI/CD ワークフローのためのロールバック戦略、各パイプラインの失敗を明確な停止、停止、または復元アクションにマップします。

Native ビルドとウェブ層リリースを分離することから始めます。Native ビルドではアプリのバイナリが変更されます。OTA バンドルではすでにインストールされているバイナリが実行できるようにする code を変更します。パイプラインにこのルールを記述することで、Native依存関係が誤ってOTAリリースに含まれないようにすることができます。

次に、リリースジョブに固定ステージの数が少ないものを設定してください。

1. 依存関係をロックしたものをインストールしてください。
2. タイプチェックとユニットテストを実行してください。
3. ウェブアセットを構築する。
4. アプリのSmokeテストを実行してください。
5. 非生産チャンネルにバンドルを公開してください。
6. テスト済みバンドルを生産に昇格してください。

デプロイ用トークンに保護されたシークレットを使用してください。トークンはリポジトリに保存してください。ジョブログに表示してください。生産ジョブに別の承認ルールを付与する必要がある場合は、チームが人間のチェックを必要とする場合にのみ、生産ジョブに別の承認ルールを付与してください。

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つのドリルを実行する。

1. リードネスチェックに合格しないバンドルを公開する。
2. インストール後に制御されたエラーをトリガーする。
3. 安定バンドルに戻り、リードネスを報告することを確認する。

各ドリルを計測する。問題を検出するのにかかる時間、露出を一時停止するのにかかる時間、安定バンドルに戻り、回復を確認するのにかかる時間を測定する。数値はチームに有益なインシデントの目標を与える。

自動化は短いネットワークのダウンタイムをアプリの失敗と誤認する可能性があるため、リリースの所有者は自動アクションを一時停止し、信号を検査し、安全な場合に前方の修正を選択できるようにする必要がある。

詳細なCapacitorのロールバック手順については、Capacitorのロールバック管理のガイドを参照してください。 Capgoのロールバック管理のガイドでは、バンドル選択、更新の適用、リードネスチェック、ステージングテストなどをカバーしています。 自動ロールバックを使用して迅速な収束を実現するが、レビューを省略する許可ではありません。安全なシステムは、早期に悪いリリースを検出して、エンジニアに根本原因を修正するための明確な方法を提供します。

6. リバースプラットフォームの運用後

モバイルアプリロールバックプラットフォームには、リリース後も運用ルーチンが必要です。誰かがリリースを監視し、停止するか、ロールバックするか、ロールフォワードするかを決定し、回復パスを準備する必要があります。

最初のプロダクションロールアウト前に、明確な役割を割り当ててください:

リリースオーナー:

• バンドルをプロモートし、変更を記録します。 インシデントオーナー:
• 停止するか、ロールバックするか、ロールフォワードするかを決定します。 ロールバックプラットフォームの運用ルーチンは、リリース後も継続する必要があります。
• サポート担当者: ユーザーからの報告を監視し、共通の症状を共有する。
• エンジニアリング担当者: 問題を追跡し、修正を準備する。

リリース後、一定のポイントでダッシュボードを確認する。早期採用を最初にチェックし、クラッシュ、起動時間、失敗した要求、主なユーザーアクションを検査する。10分後に正常に表示されるリリースは、ユーザーがよりまれなフローに到達したときにまだ失敗する可能性がある。

大規模な艦隊向けにはリングベースのロールアウトを使用する。最初のリングには、さまざまなデバイスモデルとネットワーク条件を含める。開発者だけの新しい電話で埋めないようにする。ユーザーが古いハードウェアまたはストレージが限られている場合に直面する問題を表示しない。

企業向けの展開では、チャネルをリスクにマップする。配送または支払い用のデバイスには、内部ニュース用のデバイスよりも厳密なゲートが必要である。ロールアウトグループから外に保管するリコバリーデバイスがあるようにして、インシデントの際にオペレーターが管理ツールにアクセスできるようにする。

リリース管理では、コミュニケーションも含まれる。サポートに変更を伝え、リリースIDと症状を提供する。ロールアウトを停止した場合、次のチェック時間を説明する。明確なメモは、重複した報告を減らし、ストレスの下でランダムな変更をしないようにする。

インシデント後、すべてのロールバックをレビューする。問題を捕捉したもの、見落とされたもの、トリガーが早すぎたかどうかを尋ねる。次に、テストケースまたは閾値を更新する。ロールバックは、最初に障害の際に有効であり、次のリリースの証拠としても有効である。

古いバンドルを、ポリシーが必要な限りだけ保存してください。バージョンが多すぎると選択が難しくなります。バージョンが少なすぎると、フォールバックが失われます。保存期間のルールを設定し、新しいチームメンバーが理解できるように安定版のリリースをラベル付けしてください。

アクセス制御も重要です。生産環境の公開を制限し、高リスクの変更には2回目のレビューを必要とします。バンドルをアップグレードしたりリバートしたりしたユーザーを記録するため、監査レコードを保存してください。Capgo チームは、リリースデータの取り扱い方法を記述する際に、Capgo Data Policy を参照できます。 Capgo Data Policy 実際のインシデントの際にプロセスが明確であることを確認するために、回復ドリルを計画してください。テストチャネルと無害な障害を使用し、リリースを作成しない人がロールアウトを停止し、安定版のバンドルを復元できるようにしてください。

目標は、安全な変更の場合に速く、信号が不明な場合に慎重に、ルールがわかっている場合に自動化されるリリースです。

FAQ

__CAPGO_KEEP_0__ は、__CAPGO_KEEP_1__ と Ionic チームが OTA 更新とロールバック制御が必要な場合に最適な選択です。自動ロールバック、差分更新のサポート、CI/CD統合、リアルタイム分析を含む、組織ごとにサブスクリプションを必要とするサービスです。また、14日間の無料試用版も提供されているため、チームはリリースパスを生産環境で使用する前にテストできます。

Capacitor は実際にロールバックできるのですか?

Capgo は Capacitor のチームと Ionic チームに適しています。OTA の更新とロールバックの制御が必要な場合に最適な選択です。自動ロールバック、差分更新のサポート、CI/CD統合、リアルタイム分析を含む、組織ごとにサブスクリプションを必要とするサービスです。また、14日間の無料試用版も提供されているため、チームはリリースパスを生産環境で使用する前にテストできます。

__CAPGO_KEEP_0__ は実際にロールバックできるのですか?

モバイルアプリは、OTA Web層のバンドルを巻き戻すことができますが、すでにアプリストアからインストールされているネイティブバイナリを消去することはできません。巻き戻しは、インストール済みのネイティブシェルが以前のバンドルを実行できる場合にのみ機能します。ネイティブプラグイン、権限、依存関係の変更はすべて新しいストアリリースが必要です。

自動巻き戻しはどうやって動作するのですか?

自動巻き戻しは、バンドルがインストールされた後、ヘルスシグナルを監視します。リリースがセットされた失敗ルールを超えると、システムはプロモーションを停止し、影響を受けたチャンネルを安定したバンドルに戻します。短いネットワーク問題から間違ったトリガーが発生した場合、無駄な回復作業が必要になります。

OTA更新後は何を監視するべきですか?

クラッシュフリーのユーザー、失敗した起動、ログインエラー、データロードの失敗、主なアクションを監視してください。各シグナルをリリース前の基準値と比較してください。突然の低下は、raw数値がまだ小さくても重要です。キャニャリチャンネルを監視して、ロールアウトを拡大する前に。

App Storeレビューは置き換えられますか?

App Storeレビューはネイティブの変更や主なアプリ機能の変更には置き換えられません。インストール済みのネイティブシェル内で更新可能なWeb層のcodeを更新できます。権限、ネイティブモジュール、ネイティブ設定の変更はすべてストアリリースが必要です。CI/CDルールにその境界を維持してください。

まとめ

Capgoを選択する際は、CapacitorまたはIonicチームが1つのリリースパスを必要とする場合に 差分更新、チャンネル、分析、CI/CD、およびロールバック。14日間の無料試用版を開始し、テストプロジェクトに接続し、1回のステージリリースを実行して、生産トラフィックを移動する。小さなドリルは、チームがトラッキング、採用、停止、ロールバックを行うことなく、推測をせずに実行できるかどうかを示すだろう。