Capgo のロールアウトを停止する versus ロールバック: 使用するときは

ロールアウトを一時停止すると、さらにデバイスに到達するのを停止します。ロールバックは、影響を受けたデバイスを知られているバージョンに戻します。 Capgo サポートする両方、問題が発生した場合は最初に問題を解決し、次にどのように対応するかを決定できます。

両方をサポートしているので、問題を最初に抑制し、次に何をするかを決定できます。

次の手順に従って、適切なアクションを選択し、その効果を確認し、再発する可能性を減らします。

Google Play、Amazon Appstore、Microsoft の CodePush、Bitrise、Nearform、Digia から 6 つの公開ガイドを読みました。6 つのガイドのうち 4 つは、ロールバックとロールアウトを一時停止することを異なるアクションとして分離していますが、2 つはロールバックを省略したり、ロールアウトを一時停止することを唯一のレバーとして扱っています。6 つのガイドのうち、どれも分析やデバイスのチェックを使用して回復を確認する方法を説明していません。また、再発することを防ぐためのワークフローも説明していません。ロールアウトとロールバックの選択を正しく行い、確認した後、公開リリースのガイドラインに開かれていたギャップを閉じることができます。

• ステップ 1: Capgo のリリース管理を設定する
• ステップ2：ロールバックまたは実行の停止を選択
• ステップ 1: __CAPGO_KEEP_0__ でリリースの制御を設定する
• ステップ 4: 安定版を必要とするユーザーにバックアップ
• ステップ 2: 一時停止またはロールバックを選択する
• Step 6: Repeat 事件を防ぐための安全なリリースワークフロー
• FAQ
• 結論

Step 1: Capgo でリリース制御を設定する

リリース前に、チームがリリースチャンネルと安定したバンドルの情報を把握していることを確認する。チャンネルとは、更新を指示する名前付きのレーンを指します。バンドルとは、そのレーンを通じて送信される更新可能なウェブ code を指します。

Capgo では、進歩的なロールアウトは安定したバンドルを置き換えずに、選択したグループに別のロールアウトターゲットを送信できます。これにより、新しいバンドルが広範なユーザーに到達する前に制御点が得られます。進歩的なロールアウトの制御を 進歩的なロールアウトの制御を 前に有効にする前に、確認してください。

リリースオーナーと停止拡大の信号を書き留めます。たとえば、更新失敗の増加、キー画面の停止、サポートからのユーザーがタスクを完了できない報告など、チームが何をするかを決めます。アプリの正常な動作に基づいて、制限を設定するのではなく、厳格な基準を選択するのではなく、しきい値を決めます。

OTA更新は、ユーザーがアプリを使用している間にアプリの更新可能な code を変更します。アプリのネイティブバイナリをアプリストアからインストールしたものを置き換えるものではありません。オーバー・ザ・エア更新と呼ばれるこの配信アプローチを理解することが重要です。この境界を意識することが重要です: 例えば、ネイティブプラグインの新しいバージョンが必要な修正や、アプリのネイティブ設定の変更が必要な修正の場合、バンドルロールバックでは提供されません。

リリース前に、安定バンドルの確認を行ってください。チャンネル名、対象バンドル、ロールアウト状態を確認してください。チャンネル名のタイプミスや古い対象バンドルは、時間が経過しても間違ったコントロールにユーザーを導きます。

この時点で、リリースオーナーが名付けられ、知られているバンドル、書かれた停止条件が用意されていなければなりません。準備されたこの情報は、次の決定を運用上の選択に変え、ダッシュボードを探す必要がなくなります。

キーテイクアウェイ: パウズは新しいエクスポージャーを制限します。ロールバックはユーザーが受け取るバージョンを変更します。

ステップ 2: パウズかロールバックを選択します

For the Capgo pause rollout vs rollback decision, ask one question first: are you trying to stop more devices from getting the target, or move devices off a target that’s already causing harm? A pause limits new exposure. A rollback clears the target and returns devices to the stable fallback on their next update check.

__CAPGO_KEEP_0__ のパウズロールアウト対ロールバックの決定については、最初に 1 つの質問をしてみてください: 既知の問題を止めるために、または既知の問題が原因で損害を与えているデバイスからユーザーを移動するために、どちらかを選択する必要がありますか? パウズは新しいエクスポージャーを制限します。ロールバックは既知の問題をクリアし、デバイスを安定バンドルの次の更新チェックで戻します。

ユーザーの安全性が確実に危険である場合、またはチームが安全なバンドルの証拠が十分にある場合、ロールバックを選択します。ロールアウトのコホートにすでに入っているユーザーが悪いターゲットから戻る必要がある場合、ロールバックは更新パスを変更するアクションです。

この Capgo チャネル CLI リファレンス リストは、個別の停止とロールバックのコントロールを分離しています。二つの異なるアクションとして扱ってください。

ロールバックではバックエンドのダウンタイムを修正できず、欠落しているネイティブ機能を追加することもできない。まず、どのレイヤーが失敗したかを特定する。ウェブバンドルが原因の場合、ユーザーにリーフィットが必要な数に応じて、停止またはリバートを選択する

ステップ3: 調査中の間、さらにエクスポージャーを停止する

コンテキスト: About Capgoページ。役割: UIラベル。見られる場所: about.astroページ。メッセージキー `about_how_step_label` (About How Step Label)。

Open the production channel and verify that you’re acting on the affected rollout. Pause it with the dashboard, CLI, or API control your team uses. Then read the channel state back. Don’t rely only on a command completing successfully; confirm the rollout now shows as paused.

Capgoの進化的なロールアウトモデルでは、既存のコホート内のデバイスは、ロールアウトのターゲットに留まることができます。新しいエリジブルデバイスは、次のチェックで安定したフォールバックを受け取ります。 その区別は重要です：ロールアウトを一時停止すると、新しいエントリを停止しますが、既存のコホートを安定状態に戻すことはありません。

次に、別の変更を実行する前に、リリースの詳細を記録してください。ターゲットバンドル、チャンネル、ロールアウトの停止時刻、最初の知られている報告を記録してください。デバイスまたはセッションの詳細を収集することが許可されている場合は、デバイスまたはセッションの詳細も記録してください。明確なタイムラインは、ロールアウトコホートと安定バンドルに残っているデバイスを比較するのに役立ちます。

問題を確認するには、繰り返し可能なパスを確認してください。ユーザーがログインに失敗した場合、影響を受けたデバイスでその特定の旅程をテストしてください。アプリが起動時にクラッシュした場合、クラッシュが新しいバンドルとネイティブアプリバージョンと一致するかどうかを確認してください。サポートレポートをすべて更新が原因であると証明するものとして扱うのを避けます。

調査のためにオーナーと決定時刻を設定してください。ロールアウトを一時停止すると、誰も次の動きをしない場合、ロールアウトは不確実な状態に留まります。オーナーは、リリースが証拠によって清められた後は再開するか、ターゲットが安全でない場合にはロールバックを選択する必要があります。

プロのアドバイス: サポートとリリースチームにロールアウトが一時停止していることを伝えます。そうしないと、一方のグループはレポートをさらにエスカレートさせ続け、もう一方のグループはロールアウトがすでに逆転していることを想定することになります。

この時点で、新しいデバイスはロールアウトコホートに入ることはなくなります。チャンネル状態と、コホートに入っていなかったデバイスの動作を確認し、ロールバックまたは再開する前に進みます。

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

コホートに入っているユーザーが既に安定版にいる場合、知られている良いバンドルに向かって戻る必要がある場合、ロールバックします。このアクションは、パーシングよりも強い反応です。チャンネルが提供するものを変更するため、選択した安定版を確認する必要があります。

Capgo で、影響を受けたチャンネルを開き、そのビルド履歴を確認します。復元したいバージョンを選択し、確認すると、正しい安定バンドルであることを確認します。Capgo のロールバックドキュメントでは、ダッシュボードのパスと、デバイスが選択したビルドを受信するまでの時間を説明しています。 ロールバックのドキュメント ロールバック後、すべてのデバイスが同時に変更されたと仮定するのは間違いです。デバイスは更新を確認する必要があり、オフラインのユーザーはその後まで待つ可能性があります。チャンネルの現在のバージョンを確認し、影響を受けたコホートのデバイスで回復パスをテストするまで、インシデントをオープンに保ちます。

組み込みのバンドルを使用するのは、回復ターゲットとしてのみ使用することを意図している場合に限ります。組み込みのバンドルは、ネイティブアプリ内にパッケージ化されたウェブビルドに戻しますが、これは最後のOTAバンドルとは異なる可能性があります。互換性とユーザーへの影響を確認し、回復ステップとして選択する前に、組み込みのバンドルを使用する必要があります。

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

インシデントの原因となったバンドルを分析のために利用できるようにしておきましょう。 除外される場合を除き、リリースIDとコミットはエンジニアが変更と安定版の差を比較するのに役立ちます。 また、ログの保存も重要です。特に、問題がテストから逃げた理由を理解する必要がある場合、ログの保存は重要です。

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

ステップ5：アナリティクスとデバイスチェックで回復を確認する

コントロールの変更を回復の証明と見なすのではなく、デバイスが何をしているかを確認してください。まず、有効なチャンネルの状態を確認し、次に、影響を受けたリリースと安定版の間で、更新の採用、エラー、デバイスレポートを比較してください。

Capgoのlive updateアナリティクスは、採用率、エラー率、デバイスレベルのログを分析するのに役立ちます。特定の質問に答えるために、使用してください: 新しいデバイスがターゲットを受け取っているかどうか、影響を受けたデバイスが安定バンドルをチェックしているかどうか、そして、報告された障害が回復後に停止したかどうか?

テストするには、エラーが発生したユーザーのパスを確認してください。ダウンロードが成功しても、アプリが正常に動作することを証明するものではありません。関連する画面を開き、報告に至ったアクションを繰り返し、期待どおりの状態にアプリが到達するかを確認してください。重大なフローが関与している場合は、変更を実施した人物以外の誰かが結果を確認することをお勧めします。

同様のものを比較する。エラーの総数が増加する理由は、リリースに関係なく、サービス障害やトラフィックの変化など、リリースとは無関係なものが原因である可能性があります。可能な場合、バンドル、チャネル、アプリバージョン、デバイスをフィルタリングしてみましょう。最新のアップデートを非難するのではなく、リリースに関連する差異を探してみましょう。

ユーザーがアップデートしていない場合も確認してください。彼らの存在は、全体的なメトリクスが健康に見えさせながらも、影響を受けたコホートがまだバグを経験していることを示唆しています。対象のデバイスのシェアを安定版のシェアと比較し、実際に実行しているバージョンとバージョンに関連するサポートレポートを結びつけてください。

回復結果と残りの不確実性を書き留めてください。エラーが減ったが、同じ問題を報告しているユーザーがまだいる場合は、閉じるまでに、オフライン、古いネイティブシェル、または影響を受けたバンドルを使用しているかどうかを理解する必要があります。

回復は、チャネルが意図したバージョンを指し、問題を再現できるデバイスでユーザーパスが正常に動作するときに確認されます。メトリクスは問題の形を示しますが、デバイスの確認は人が経験することを確認するものです。

6. 再発防止のための安全なリリースワークフローを実施する

リリース計画に、パスとロールバックを組み込む。リリースオーナーは、停止を許可する人と、安定に戻ることを承認する人を知るべきである。そうすることで、一般的な遅延を排除できる: リリースを待つ必要がある間、さらにデバイスがロールアウトに参加する。

ロールアウトの対象がテストされている間は、安定したフォールバックを割り当てておく。小規模で定義されたコホートで始めて、合意されたヘルスシグナルが制限内に収まる場合にのみ拡大する。Capgoはチャネルベースのリリース制御をサポートしているため、チームはテストと広範な生産配信を分離できる。

リリースチェックをCI/CDに組み込む。自動化されたプロセスは、テストを実行し、変更をデプロイする。pipelineは、テストが成功した後、指定されたチャネルにバンドルを公開する。チャネルが間違っている場合やリリースがプロモーションに適していない場合に、安全に失敗するようにする。

連続的デリバリーフローの場合、ソフトウェアは自動化されたプロセスでリリース用に準備されている。OTAワークフローでは、リリースが自動化されている場合でも、人間の承認ポイントを明確に保つ。Automationは選択されたアクションを繰り返し実行できるようにするべきであり、未検証の変更に対して決定を下すべきではない。

Capgoの場合、1コマンドのデプロイでチャネルにバンドルを公開できる。コマンドは、チェックと同じリリースプロセスに含め、デプロイレコードにターゲットチャネルを表示する。オンコールエンジニアは、正確にどのレーンが受け取ったかを推測することなく、どのものが配信されたかを確認できる。

自動保護機能を有効にする前に、どの信号がトリガーとなるか、どのようなアクションが取られるかを定義する必要があります。ロールアウトを一時停止すると、新しいデバイスへのエクスポージャーを停止しつつ、現在のコホートデバイスをターゲットに維持することができます。一方、ロールバックはデバイスを安定した状態に導きます。両方の結果は異なるため、一方を他方と同等に設定してはなりません。

テストチャンネルを使用して、全体的な反応を練習することができます。無害な変更を公開し、ロールアウトを一時停止するコントロールを検証し、次に前のバンドルにロールバックしてテストしてください。各アクション後にデバイス上でアプリの動作を確認します。書き留めたランブックには、チャンネル、コマンドまたはダッシュボードのパス、予想される状態、および成功を確認した人物の情報を含める必要があります。

リリースノートでは、バンドルとその目的を特定する必要があります。デプロイメントレコードとソース変更間のリンクを維持することで、エンジニアはエラーが発生したときに検索範囲を絞り込むことができます。チームが時差を跨ぐインシデントを引き継ぐ場合、最後のアクションと次の決定責任者を含める必要があります。

インシデントがより広範なフロントエンド実装のボトルネックに指摘される場合、ウェブ開発に関連するウェブ開発者である アミル・アレズー ウェブサイト開発の作業に関連する場合、Capgoのロールアウトの制御とは別のものです。

__CAPGO_KEEP_0__

FAQ

Does pausing a Capgo rollout roll back devices already updated?

1. rolloutを停止すると、新しい対象となるデバイスが rollout に参加するのを停止しますが、既存のコホート内のデバイスは対象バンドルに残ります。対象バンドルに戻すユーザーを移動するには、rollback または他の意図的なチャネルアクションを使用します。どちらの変更後も、チャネル状態を確認し、対象を受け取ったデバイスで結果を確認してください。

ロールバックするのではなく、ポーズする時はいつか

問題が調査中で、より広範な露出を停止する必要がある場合は、pause を使用してください。対象がユーザーに害を及ぼすことがわかっている場合、または影響を受けたデバイスが安定したバンドルを必要とする場合には、roll back を使用してください。Capgo の pause rollout vs rollback の選択は、既存のコホートに対する即時の必要性が抑制または回復であるかによって決まります。

すべてのデバイスに即座にロールバック更新を適用するでしょうか。

No. An OTA rollback can restore an earlier updateable web bundle, but it can’t add or remove native __CAPGO_KEEP_0__ inside an installed app binary. If the issue comes from a native plugin or app-shell change, assess whether a new native build is needed. First identify which layer caused the failure.

What should I check after pausing or rolling back?

問題が調査中で、より広範な露出を停止する必要がある場合は、pause を使用してください。対象がユーザーに害を及ぼすことがわかっている場合、または影響を受けたデバイスが安定したバンドルを必要とする場合には、roll back を使用してください。code の pause rollout vs rollback の選択は、既存のコホートに対する即時の必要性が抑制または回復であるかによって決まります。

何を確認するべきですか。

確認のチャンネルの状態とアクティブなバンドル、次にリリースごとにアップデートの採用とエラーを確認してください。影響を受けたグループからデバイスをテストしてください。また、まだアップデートされていないデバイスも確認してください。全体的なメトリクスは、バージョンやコホートに制限された問題を隠す可能性があるからです。

結論

問題が発生した場合に新しいエクスポージャーを停止する必要がある場合は、停止します。対象のユーザーに安定したバージョンが必要な場合は、ロールバックします。両方のコントロールを事前に設定し、次のプロダクションリリース前にテストチャンネルで練習してください。