Capgo ロールアウトの一時停止とロールバック：使い分けのタイミング

一時停止（Pause）はロールアウトがそれ以上デバイスに届かないようにするもの、ロールバック（Rollback）は影響を受けたデバイスを既知の正常なバージョンに戻すものです。 Capgo 両方に対応しているため、まずは問題を封じ込めてから、次のアクションを決定できます。

適切なアクションを選び、その効果を確認し、同じインシデントの再発リスクを下げるための手順です。

Google Play、Amazon Appstore、Microsoft の CodePush、Bitrise、Nearform、Digia が公開している、ステージドロールアウトとロールバックに関する6つのガイドを読みました。6つのうち4つは「一時停止」と「ロールバック」を別個のアクションとして区別していますが、2つはロールバックに触れていないか、一時停止だけを手段として扱っています。また、6つのどれも、アナリティクスやデバイスチェックで復旧を確認する方法や、再発防止のワークフローについては説明していません。「一時停止かロールバックか」を正しく選び、その結果を確認することは、公開されているリリースガイドに共通して残るギャップを埋めます。

目次

• ステップ 1: Capgo でリリース制御を設定する
• ステップ2: 一時停止またはロールバックを選択
• ステップ3: 調査中は、さらなる配信を一時停止する
• ステップ4: ユーザーが安定版を必要とする場合にロールバック
• ステップ5: アナリティクスとデバイスチェックで復旧を確認
• ステップ 6: より安全なリリースワークフローで再発を防ぐ
• よくある質問
• まとめ

ステップ 1: Capgo でリリース制御を設定する

インシデント発生前に、どのチャンネルがリリースを配信していて、どのbundleが安定版なのかをチームが把握しているようにしてください。チャンネルは、アプリのデバイスをアップデートに振り分ける名前付きのレーンです。bundleは、そのレーンを通じて送信される更新可能なWeb codeです。

Capgo では、プログレッシブロールアウトを使うことで、安定版のbundleを維持したまま、選択したグループに別のロールアウト対象を送信できます。これにより、新しいbundleがより広いユーザー層に届く前に、制御ポイントを確保できます。まず、 プログレッシブロールアウトの制御設定を 本番環境で有効にする前に確認してください。

リリース責任者と、展開を止めるべきシグナルを書き留めておきましょう。例えば、アップデート失敗が増えた、主要画面が動かなくなった、サポートからユーザーがタスクを完了できないと報告があった、といった場合にチームがどう動くかを決めます。上限は、厳しそうに聞こえるからという理由で閾値を選ぶのではなく、アプリの通常の動作に基づいて設定してください。

OTAアップデートは、アプリの更新可能な code を無線経由で変更するものです。App Storeからインストールされたネイティブアプリのバイナリを置き換えるものではありません。「over-the-air update」という用語は、この配信手法を指します。この線引きは忘れないでください。修正に新しいネイティブプラグインやネイティブ設定の変更が必要な場合、bundleのロールバックでは対応できません。

リリース前に、安定版のbundleが想定どおりであることを確認してください。チャンネル名、ターゲットbundle、ロールアウト状態をチェックしましょう。一刻を争う場面では、チャンネル名のタイポや古いターゲットが、対応者を誤ったコントロールへ導くことがあります。

この時点で、リリース責任者を指名し、動作確認済みのバンドルを特定し、停止条件を文書化しておく必要があります。その準備があれば、次の判断はダッシュボードで慌てて探すのではなく、運用上の選択になります。

重要なポイント: 一時停止は新規配信を制限します。ロールバックは、ユーザーに配信されるバージョンを変更します。

ステップ2: 一時停止またはロールバックを選択

Capgo でロールアウトを一時停止するかロールバックするかを判断するときは、まず1つ質問してください。これ以上デバイスにターゲットを配信したくないのか、それともすでに問題を引き起こしているターゲットからデバイスを外したいのか。一時停止は新たなデバイスへの配信を抑えます。ロールバックはターゲットを解除し、次回のアップデート確認時にデバイスを安定版のフォールバックに戻します。

証拠が不十分なときや、問題が限定的に見えるときは「一時停止」を選んでください。報告が数件あっても、そのバグが特定のデバイスタイプだけに影響するのか、特定のユーザーフローなのか、アップデート済みの全デバイスなのかが分からないことがあります。一時停止すれば、ロールアウトグループに新しいデバイスを追加せずに、チームがシグナルを調査する余地を確保できます。

ターゲットがユーザーにとって明らかに安全でない場合、または正常動作が確認済みの bundle の方が安全だという十分な証拠がある場合は「ロールバック」を選んでください。一時停止だけでは、すでにロールアウト対象に含まれているデバイスから問題のあるターゲットを取り除けません。それらのユーザーを安定版に戻す必要がある場合、アップデート経路を変えるアクションはロールバックです。

この Capgo チャネル CLI リファレンス 一時停止とロールバックのコントロールは別々に用意されています。同じ「緊急停止」の別名ではなく、異なるアクションとして扱ってください。

ロールバックではバックエンドの障害は解決できず、不足しているネイティブ機能を追加することもできません。まず、どのレイヤーで失敗したかを特定してください。Web bundleに問題がある場合は、救済が必要なユーザー数に応じて、一時停止するかリバートするかを選びます。

ステップ3: 調査中は、さらなる配信を一時停止する

新しいデバイスをロールアウトグループに入れたくないが、すでに参加しているデバイスのターゲットを戻す準備ができていないときは一時停止します。これは封じ込めのための措置です。問題が他のユーザーに広がるのを防ぎながら、事実確認の時間を稼げます。

プロダクションチャンネルを開き、影響を受けているロールアウトに対して操作していることを確認します。ダッシュボード、CLI、またはチームが使っている API で一時停止してください。その後、チャンネルの状態を読み直します。コマンドが正常に完了しただけで判断せず、ロールアウトが一時停止として表示されることを確認しましょう。

Capgo の段階的ロールアウトモデルでは、一時停止後も、すでにコホートに入っているデバイスはロールアウトターゲットのまま残ることがあります。新たに対象となったデバイスは、次回のチェックで stable へのフォールバックを受け取ります。この違いは重要です。一時停止は新規の参加を止めますが、既存のコホートを stable に戻すわけではありません。

次に、別の変更を加える前に対象リリースの詳細を記録します。対象の bundle、チャンネル、一時停止した時刻、最初に確認されたレポートを残してください。チームが収集を許可されている範囲で、デバイスやセッションの詳細も記録します。明確なタイムラインがあると、ロールアウトのコホートと、まだ stable バンドルを使っているデバイスを比較しやすくなります。

再現できる手順で問題を確認します。ユーザーがログイン失敗を報告したら、影響を受けているデバイスでその一連の操作をそのまま試してください。起動時にクラッシュする場合は、そのクラッシュが新しい bundle とネイティブアプリのバージョンに一致するか確認します。サポートへの報告をすべて、アップデートが原因だという証拠として扱うのは避けましょう。

調査の責任者と意思決定の期限を明確にしてください。責任者が不在だと、ロールアウトの一時停止が宙ぶらりんの状態になりがちです。責任者は、リリースに問題がないと判断されたら再開し、ターゲットが依然として安全でない場合はロールバックを選択すべきです。

プロのヒント: サポートチームとリリースチームに、ロールアウトが一時停止されたことを通知してください。そうしないと、あるチームが報告をエスカレーションし続ける一方で、別のチームがロールアウトがすでに巻き戻されたと誤解する可能性があります。

この時点で、新しいデバイスがロールアウトのコーホートに追加されてはいけません。ロールバックまたは再開に進む前に、チャネルの状態と、コーホートに含まれていなかったデバイスの動作を確認してください。

ステップ 4: ユーザーが安定版を必要としている場合にロールバックする

ターゲットにすでに適用されているユーザーが、既知の正常なバンドルに戻す必要がある場合にロールバックします。これは一時停止よりも強力な対応です。チャネルが配信する内容が変わるため、アクションを確認する前に選択した安定版ビルドを検証してください。

Capgoで、影響を受けたチャネルを開き、ビルド履歴を確認します。復元したいバージョンを選択し、それがこのアプリとチャネルにとって正しい安定版のbundleであることを確認してください。Capgoの ロールバックドキュメント は、ダッシュボード上の操作手順を説明し、デバイスが次にアップデートを確認した際に選択されたビルドが配信されることを示しています。

ロールバック後、すべてのデバイスが即座に変更されたとは考えないでください。デバイスはアップデートを確認する必要があり、オフラインのユーザーは後になってから確認する可能性があります。影響を受けたコホートのデバイスで復旧パスをテストし、チャネルのアクティブバージョンを確認するまで、インシデントをオープンに保ってください。

組み込みのbundleは、それが意図された復旧ターゲットである場合のみ使用してください。これは、ネイティブアプリ内にパッケージされたWebビルドにデバイスを戻しますが、最後のOTA bundleとは異なる場合があります。復旧ステップとして選択する前に、互換性とユーザーへの影響を確認してください。

保持ポリシーに別の定めがない限り、インシデントの原因となったbundleは分析のために保持してください。リリースIDとコミットは、エンジニアが変更点を安定版と比較するのに役立ちます。特に、問題がテストをすり抜けた理由を理解する必要がある場合は、クリーンアップ前に関連するログを保存してください。

ロールバックは、すべての障害に対する正しい修正ではありません。根本原因がサーバーサイドの依存関係である場合は、そのサービスを修復してください。変更がインストール済みバイナリに存在しないネイティブcodeに依存している場合は、ネイティブビルドを準備し、その変更に対してアプリストアのリリースパスに従ってください。

ステップ5: アナリティクスとデバイスチェックで復旧を確認

一時停止やロールバック後は、制御変更を復旧の証拠とせず、デバイスの実際の動作を確認してください。まずアクティブなチャネルの状態を確認し、その後、影響を受けたリリースと安定版の間で、アップデートの採用率、エラー、デバイスレポートを比較してください。

Capgoのlive update analyticsを使えば、導入状況のメトリクス、エラー率、デバイス単位のログを確認できます。これらのシグナルから、「新しいデバイスにターゲットがまだ届いているか」「影響を受けたデバイスが安定版bundleをチェックしているか」「復旧後に報告された障害が止まったか」といった具体的な問いに答えられます。

失敗したユーザーパスをテストしてください。ダウンロードが成功しても、アプリが正常に動作するとは限りません。該当する画面を開き、報告につながった操作を再現して、アプリが期待どおりの状態になるか確認してください。インシデントがクリティカルなフローに関わる場合は、変更を加えた本人以外に結果を確認してもらいましょう。

条件を揃えて比較しましょう。全体のエラー数は、サービスの不具合やトラフィックの変化など、リリースとは無関係な理由で増えることがあります。これらのフィールドが利用できる場合は、bundle、channel、アプリバージョン、デバイスでフィルタリングしてください。安易に最新アップデートのせいにするのではなく、リリースに起因する差異を探しましょう。

アップデートしていないユーザーも確認してください。そうしたユーザーがいると、影響を受けているグループでバグが続いていても、全体のメトリクスは健全に見えてしまいます。ターゲット上のデバイス割合と安定版上の割合を追跡し、サポート報告はユーザーが実際に使用しているバージョンに紐付けてください。

復旧結果と残る不確実性を記録してください。エラーが減っても一部のユーザーが同じ問題を報告しているなら、そのユーザーがオフラインなのか、古いネイティブシェルを使っているのか、影響を受けたbundleをまだ使っているのかを把握するまで、インシデントをクローズしないでください。

チャンネルが意図したバージョンを指し、失敗していたユーザーパスが問題を再現できるデバイスで動作すれば、復旧は確認できたことになります。メトリクスは問題の全体像をつかむのに役立ち、デバイスでの確認が実際のユーザー体験を裏付けます。

ステップ 6: より安全なリリースワークフローで再発を防ぐ

公開前に、一時停止とロールバックをリリース計画に組み込んでおきましょう。リリース責任者は、誰が配信を止められ、誰が安定版への切り戻しを承認できるかを把握しておくべきです。これにより、ロールアウトに加わるデバイスが増える中で会議を待つ、というよくある遅延を防げます。

ロールアウト対象をテストしている間は、安定版のフォールバックを割り当てたままにしてください。まずは小規模で明確に定義されたコホートを使い、合意したヘルスシグナルが許容範囲内に収まっている場合にのみ拡大してください。Capgo はチャンネルベースのリリース制御をサポートしているため、チームはテストと本番全体への配信を分けて行えます。

テストを実行して変更をデプロイする自動プロセスであるCI/CDに、リリースチェックを組み込みましょう。パイプラインは、テスト通過後に目的のチャンネルへbundleを公開できます。また、チャンネルが誤っている場合や、リリースがプロモーション可能な状態でない場合は、安全に失敗するようにすべきです。

継続的デリバリーのワークフローは、自動化されたプロセスによってソフトウェアをリリース可能な状態に保ちます。OTAのワークフローでは、公開が自動化されていても、人間の承認ポイントを明確にしておきましょう。自動化は、選んだアクションを再現可能にするものであり、未レビューの変更について判断を下すものではありません。

Capgo なら、コマンド1つのデプロイで bundle をチャンネルに公開できます。このコマンドはチェックと同じリリースプロセスに組み込み、デプロイ記録で対象チャンネルが分かるようにしましょう。そうすればオンコール担当のエンジニアは、どのレーンに配信されたかを推測せずに、何が配信されたかを正確に把握できます。

自動セーフガードを有効にする前に、どのシグナルで発動し、どのアクションを取るかを定義してください。Pause は、現在のコホートのデバイスをターゲットに残したまま、新たな露出を止められます。Rollback は、デバイスを stable へ誘導します。結果が異なるので、一方を他方のつもりで設定しないでください。

テスト用チャンネルで対応全体をリハーサルしましょう。無害な変更を公開し、Pause コントロールを確認してから、以前の bundle へのロールバックをテストします。各アクションの後は、デバイス上でアプリの挙動を確認してください。文書化したランブックには、チャンネル、コマンドまたはダッシュボードのパス、期待する状態、成功を確認する担当者を記載します。

リリースノートには、bundle とその目的を明記してください。デプロイ記録とソースの変更を紐付けておけば、エラー発生時にエンジニアが調査範囲を絞り込めます。タイムゾーンをまたいでインシデントを引き継ぐチームなら、最後に実行したアクションと次に判断する担当者を記載してください。

もしインシデントが、より広範なフロントエンド実装のボトルネックを示しているなら、次のような Web 開発者が Amir Arezoo Web サイト開発の作業に関係するかもしれません。これは、互換性のあるアプリ更新の配信とリカバリを扱う Capgo のロールアウト制御とは別です。

この時点で、リリースパスには安定したフォールバック、責任者、停止ルール、テスト済みの復旧アクションが含まれているはずです。オンコールエンジニアがプレッシャー下でも使用できるほど、ワークフローを短く保ってください。

よくある質問

Capgo のロールアウトを一時停止すると、すでに更新済みのデバイスはロールバックされますか？

いいえ。一時停止は、新しい対象デバイスがロールアウトに入るのを防ぎますが、すでにコホートに含まれているデバイスはターゲットバンドルを維持し続ける可能性があります。これらのユーザーを安定版に戻すには、ロールバックまたは別の意図的なチャネル操作を使用してください。いずれの変更後もチャネルの状態を確認し、ターゲットを受信したデバイスで結果を検証してください。

ロールバックではなく一時停止すべきタイミングはいつですか？

問題がまだ調査中で、影響の拡大を止めたいときは一時停止します。対象がユーザーに害を及ぼすと分かっている場合、または影響を受けたデバイスに安定した bundle が必要な場合はロールバックします。Capgo でロールアウトを一時停止するかロールバックするかは、既存のコホートに今必要なのが封じ込めか復旧かで決まります。

ロールバックすると、すべてのデバイスがすぐに更新されますか？

いいえ。ロールバックは channel が指す bundle を変更しますが、デバイスは次に更新を確認したときにそれを受信します。オフラインのデバイスは、再接続するまで現在の bundle のままになる可能性があります。channel のターゲットを確認し、インシデント解決を宣言する前に、影響を受けたデバイスとその更新ステータスを確認してください。

OTA ロールバックでネイティブアプリの問題を修正できますか？

いいえ。OTA ロールバックは以前の更新可能な web bundle を復元できますが、インストール済みアプリのバイナリ内にあるネイティブ code を追加または削除することはできません。問題がネイティブプラグインやアプリシェルの変更に起因する場合は、新しいネイティブビルドが必要か判断してください。まず、どのレイヤーで失敗したのかを特定してください。

一時停止またはロールバック後、何を確認すべきですか？

channel の状態とアクティブな bundle を確認し、リリース別に更新の適用状況とエラーをチェックしてください。影響を受けたグループのデバイスで、失敗したユーザージャーニーをテストしてください。まだ更新されていないデバイスも確認してください。全体の指標では、特定のバージョンやコホートに限られた問題が見えなくなることがあるためです。

まとめ

調査中に新たな露出を止めたいときは「Pause」を、ターゲットのユーザーに安定したバージョンが必要なときは「Roll back」を使います。両方のコントロールを事前に設定し、次の本番リリース前にテストチャンネルでリハーサルしておきましょう。