低い試行回数の閾値は、健康なOTAロールアウトを一時停止させることができます。一方、高い閾値は、不良のバンドルが多くのデバイスに到達することを許します。Capgo 自動一時停止最小試行回数 設定は、Capgoがインストールと失敗データを収集するのに十分なデータを持っている場合にチャンネルを一時停止するときに制御します。以下の手順に従って、十分な注意を払って設定し、テストし、リリースフローに接続してください。
目次
- ステップ 1: 最小試行回数が制御するものを理解する
- ステップ 2: Capgoの自動一時停止設定を探す
- ステップ 3: 安全な最小試行回数の値を選択する
- ステップ 4: チャネルベースのロールアウトで自動停止をテストする
- ステップ 5: 試行回数、分析、自動ロールバックを監視する
- ステップ 6: CI/CDで設定を自動化する
- FAQ
- 結論
ステップ 1: 最小試行回数の制御を理解する
The 最小試行回数の値は、__CAPGO_KEEP_0__の停止ルールが作用する前に必要な最小サンプル数を設定します。ゲートであり、失敗制限ではありません。この設定は、__CAPGO_KEEP_1__に、十分な更新試行が存在するまでロールアウトを待つように指示します。 value sets the smallest sample Capgo needs before its pause rules can act. It is a gate, not a failure limit. The setting tells Capgo to wait until enough update attempts exist before judging the rollout.
__CAPGO_KEEP_0__のチャネル参照では
Capgoのチャンネルリファレンスはauto-pause-min-attemptsインストールと失敗試行の合計数として表します。CLIの参照では文字列として表現されるため、コマンドまたはAPIを使用する際の値の形式を維持してください。 Capgo チャネル CLI フィールド ライブ チャネルを変更する前に。
この設定を最小の証拠規則として考えてみましょう。1 の値は最初の記録された試行後に反応する可能性があります。これは、非常に小さな内部テストの場合に役立ちますが、1 つの悪いネットワーク セッションに反応する可能性もあります。より大きな値は、ロールアウトに有用なサンプルを収集するのに十分な時間を与えます。
ユーザー間の試行を分離する
試行はユニークなユーザーと同じではありません。1 つのデバイスはアップデートを再試行する可能性があります。1 つのユーザーは複数のデバイスでアプリを実行する可能性があります。アナリティクス ビューも、ユーザーの製品メトリクスと異なる方法でイベントをグループ化する可能性があります。
値を選択する前に、保護したい閾値を書き留めてください。目標は、早期に破損した JavaScript バンドルを捕捉することなので、低い値を使用する小規模な制御チャネルが使用できます。目標は、広範な生産リリースを保護することなので、1 つのデバイスまたは短いダウンタイムに基づく決定を避けるために十分な試行を必要とします。
- プライベート テスト チャネルでは、小さな閾値を使用します。
- 混合ネットワークとデバイスの種類を持つチャネルでは、大きな閾値を使用します。
- 短いダウンタイムが誤った停止を引き起こしている場合は、閾値を上げてください。
- 誤った停止のコストが遅い検出のコストよりも高くなった場合にのみ、閾値を下げてください。
Auto-pause はロールアウトを停止する必要がありますが、バンドルレビュー、デバイステスト、明確なロールバック計画の代わりではありません。閾値を 1 つのリリースプロセスの制御として扱ってください。
キータイクエイク: ロールアウト証拠の Capgo が自動停止ポリシーが作用する前に必要な試行回数を制御します。
ステップ 2: Capgo の自動停止設定を探します。
設定する Capgo __CAPGO_KEEP_0__ ダッシュボードから始めて、またはチームがすでに使用している __CAPGO_KEEP_1__ パスを使用してチャネルコマンドを使用してください。チャンネル名を確認する前に編集を開始しないでください。テストチャンネルと生産チャンネルは似た名前を持つ可能性があり、間違ったチャンネルに正しい値を設定すると、リリースのインシデントが待ち受けていることになります。
Start in the Capgo dashboard or use the channel command and API path your team already uses. Check the channel name before you edit anything. A test channel and a production channel may have similar names, and a correct value on the wrong channel is still a release incident waiting to happen.
Look for the auto-pause fields in the channel settings. The related fields may include the minimum attempts value and a confidence setting. Keep those fields together in your change review. A minimum sample says when Capgo may judge the rollout. A confidence value can affect how strong the signal must be before a pause happens.
パスを確認して値を設定できます。
Use the dashboard when you need a quick controlled change and your team records dashboard changes. Use the CLI when the setting belongs in a release script. Use the public API when a service manages channel policy as part of a wider deployment system.
どちらのパスを選択しても、古い値をキャプチャすることから始めましょう。 チャンネル名、バンドルバージョン、ロールアウト状態、そして新しい値を同じ変更レコードに保存してください。 そうすることで、チャンネルが後で停止した場合に明確な答えが得られます。
API ドライブのワークフローでは、Capgo はパブリック API を通じてチャンネルリソースを公開します。 Capgo チャンネル API ドキュメント フィールド名とリクエストの形状を確認するには、ドキュメントを参照するのが適切です。
値を編集するときは、フィールドが数値を求めているため、整数を入力してください。 パーセント記号を追加しないでください。 小数点を使用しないでください。 ツールが JSON 形式で設定を保存している場合、キーのスペルを正確に保持し、現在の Capgo リファレンスで示されている文字列形式を維持してください。
変更を確認
変更を保存した後、チャンネルを再度読み取りましょう。 成功したコマンドが実行された場合でも、意図したフィールドが変更されたことを前提にしないでください。 返されたチャンネルデータまたはダッシュボード値を確認してください。
次に、3 つの質問をしてみましょう:
- 設定が意図したチャンネルで変更されたか?
- チャンネルはまだ、意図したバンドルに指向しているか?
- ロールアウトはアクティブ、停止、または完了しているか?
値が表示されない場合は、そこで停止してください。 権限、フィールドのスペル、チャンネル識別子を確認してください。 成功を報告するデプロイメントスクリプトが保存された状態を検証しないと、信頼できません。
Step 3: 最小試行回数の安全な値を選択
CapgoのCapgo自動停止最小試行回数を、ロールアウトのサイズとリスクから選択してください。すべてのアプリには安全な数値はありません。正しい閾値は、ポリシーに十分な証拠を提供しながら、悪いアップデートを早く検出することができます。
最初は、有用な情報を得ることができる最小のグループから始めましょう。プライベートチャンネルには、内部デバイスと既知のアプリバージョンが含まれる場合があります。生産チャンネルには、古いデバイス、弱い接続、およびアプリを開くのは数日ごとにしかしないユーザーが含まれる場合があります。デフォルトでは、同じ閾値を共有しないようにしてください。
単純な決定ルールを使用
何回試行する必要があるかを尋ねてみましょう。試験チャンネルには数台のデバイスしかない場合、試験期間中に高閾値が達成される可能性は低い場合があります。生産チャンネルでは、数分以内に多くの試行が行われる場合、短いネットワーク問題の後にリリースを停止するために低い閾値を設定する必要があるかもしれません。
閾値を下げる場合
- チャンネルがプライベートである場合
- 高リスクの機能を変更するバンドルである場合
- ステージドテストの際に迅速なフィードバックが必要である場合
- リリース後すぐにすべてのエラーを検査できるチームがいる場合
閾値を上げる場合
- 生産チャンネルが幅広いデバイスの組み合わせを提供する場合
- ユーザーは不安定なネットワークを通じて接続します。
- アプリの日常開放頻度は低い。
- 短いダウンタイムは多くの誤った失敗を生み出す。
既知の問題を隠すために閾値を使用しないでください。必要なネイティブプラグインでバンドルが失敗した場合、リリースを自分で停止し、原因を修正してください。最小試行数設定では、互換性のないバンドルを安全にすることはできません。
閾値をロールアウトサイズと組み合わせてください。
例えば、内部チャネルに小さなリリースを実行します。チームが何回インストール結果を確認できるようにする閾値を選択します。バンドルがそのステージを通過した後、より広いチャネルに移動し、より大きなサンプルを反映する閾値を選択します。
このアプローチは、最初の信号を速く取得することなく、生産ポリシーが小さなサンプルに対して反応する必要がなくなるようにします。また、設定を調整する明確な場所を提供します。チャネルとともに閾値を調整し、ロールアウトがすでに失敗した後は変更しないでください。
リリースレコードの横に値を追跡してください。なぜその値を選択したのか、どのような状況で値を変更するのか、変更を承認できるのは誰なのか、書き留めてください。この情報は、チームメンバーがインシデント中に停止したチャネルを見て、すぐにコンテキストを理解できるようにするために重要です。
プロのヒント: 制御されたチャネルから始めて、試行数を記録し、観察されたロールアウトの動作に基づいて生産閾値を調整するのではなく、推測に頼るのではなくしてください。
ステップ 4: チャネルベースのロールアウトで Auto-Pause をテストしてください
テストチャンネルで自動停止をテストする前に、生産環境で依存しないようにする。チャンネルはテストの境界を与える。知られているグループにバンドルを送信し、試行が上昇し、ポリシーが閾値に達したときに何が起こるかを確認することができる。
最初に、生産リリースと混同しないように識別できるテストバンドルを作成する。code の変更は安全に保つ。テストはリリースの制御を証明することではなく、2 番目のアプリケーション問題を生み出さないようにする。
次に、テストデバイスの小さなグループをチャンネルに割り当てる。各デバイスが期待どおりのネイティブアプリケーション版を持っていることを確認する。OTA code は、ネイティブの不一致をすべて修正できないため、間違ったバイナリを実行しているデバイスはテストを読みにくくする。
チャンネルにバンドルを公開する。可能な限り通常の Capgo のデプロイフローで 1 つのコマンドを使用するが、バンドルとチャンネル ID をリリースログに残す。インシデントの際にターミナルスクロールバックバッファに頼るのではなく。
自動停止パスをテストする。
失敗した試行を安全に生産する方法が必要です。テスト専用のバンドルまたはチームによって承認された制御された失敗条件を使用する。生産バンドルを損傷させて自動停止が機能するかどうかを確認することはない。
次のシーケンスを確認する。
- チャンネルはテストバンドルを指している。
- デバイスは更新指示を受け取る。
- 試行は分析ビューに表示される。
- 最小試行数が達成される。
- 失敗信号がチャンネルを停止させる、ポリシー条件が満たされている場合。
第5ステップは重要です。最小試行回数に到達すると、自動停止が有効になります。ただし、すべてのロールアウトがその精確な数値で停止するわけではありません。
テストの復旧も行ってください
停止後、ユーザーが受け取る内容を確認してください。失敗したバンドルが選択され続けているか、新しいデバイスが受け取っていないか、前の安全なバンドルがロールバック可能な状態になっているかを確認してください。結果はアップデータとチャンネルの設定によって異なります。アプリのログを確認してください。
停止後、知られている安全なバンドルで再開するには、誰かが失敗の原因を確認するまで待ってください。失敗が不良ビルドによるものであれば、新しいバンドルを作成してください。同じアーティファクトを再度プッシュして、次の試行が異なる動作をすることを願うのではなくてください。
テスト結果を記録してください。閾値、デバイスの数、失敗条件、停止時間、復旧アクションを含めてください。これにより、一時的なテストが繰り返しリリースチェックに変わります。
ステップ5：試行回数、分析、自動ロールバックの監視
Monitoring tells you whether the Capgo auto pause minimum attempts rule is seeing a healthy rollout or a broken one. Watch the attempt count beside failure behavior. A count without context can lead you to pause too early or miss a growing issue.
Capgoを使用してCapgo Observeを実行して、更新アクティビティとロールアウトのステータスを確認します。 CapgoのObserveを使用して、更新アクティビティとロールアウトのステータスを検査してください。 codeの起動またはコアアプリフローを変更するbundleの最初の部分では、リリースの最初の部分にダッシュボードを開いておくことが推奨されます。
OTA展開の分析情報と自動ロールバック監視を表示するエリアの説明です。
信号を一緒に読み取ってください。
最初に試行回数を確認してください。次に、失敗回数と時間パターンを確認してください。成功したインストールの連続した流れは、1つのbundleが有効になるときに突然の失敗の流れと異なります。
Network failures can create noise. A short outage may produce failed attempts without a code defect. That is why the threshold should work with a confidence policy and a human review process. Auto-pause can stop exposure, but it cannot explain every failure.
フロー内でのロールバックとは何ですか。
ロールバックとは何かを理解してください。
生産環境での使用前に、テストチャンネルでロールバックパスを確認してください。安全とみなされるバンドルのバージョンを確認し、デバイスがオフラインのときにポーズ中の挙動を確認してください。次に、オンコールエンジニアが見つけることができる回復手順を書きましょう。
Capgoの ロールバックドキュメント は、利用可能なロールバックコントロールをチャンネル計画とマッピングするのに役立ちます。ドキュメントされた動作を参照してください。結果はアップデータバージョンとリリース設定によって異なる可能性があります。
障害発生時は、失敗パターンが明確な場合はまずポーズしてください。次にログとバンドル変更を調べます。数分間の暴露を停止する方が、既知の悪いリリースを広げるのと比較して管理しやすい場合が多いです。
ステップ 6: CI/CD で設定を自動化する
Put the Capgo auto pause minimum attempts value in your release workflow when the setting changes with each channel. Automation removes manual drift. It also makes the chosen threshold visible in code review.
API の自動ポーズ最小試行回数値をリリースワークフローに追加してください。設定がチャンネルごとに変更される場合、自動化は手動のずれをなくし、選択した閾値を __CAPGO_KEEP_1__ のレビューで確認できます。
リリースジョブは明確な順序で進められるべきです。
- リリースジョブは、次の順序で実行されるべきです。
- ウェブバンドルをビルドしてください。
- テストを実行し、ネイティブの互換性を確認してください。
- チャンネルを設定または確認する。
- 最小試行回数の値を適用する。
- 保存されたチャンネル状態を検証する。
- ロールアウトを公開または進める。
デプロイメントシステムがサポートする場合、ドライランまたはレビューステージを使用する。レビューでは、バンドル識別子、チャンネル、閾値、ロールアウトアクションが表示されるべきである。プロダクションステップが実行される前にこれらが表示されるべきである。
ジョブの検証を実行する。
APIまたはCLIコマンドが完了した後、チャンネル状態を再度取得する。返された値が期待される構成と一致しない場合、ジョブを失敗させる。この方法で、間違ったチャンネルID、却下されたフィールド、部分的な更新をキャッチできる。
環境変数は、CIジョブにリリース設定を渡す一般的な方法である。ジョブは、秘密をソースファイルに格納しないように、チャンネル名または閾値を読み取ることができる。変数名を明確にし、デプロイメント前に検証する。
例えば、ワークフローには次のような要件があるかもしれない。
CAPGO_CHANNELターゲットチャンネルを指定する。CAPGO_MIN_ATTEMPTS承認された閾値を指定する。CAPGO_BUNDLE_IDアップロードされたバンドルを指定する。
Capgoのワークフロー規則ではありません。Capgoのフィールド名ではありません。CLIまたはAPIのフィールドに正確にマップすることで、将来の変更を簡単にレビューできます。
CI/CDパイプラインでOTA更新をセキュアにするためのCapgoのガイドラインを確認してください。重要な習慣は簡単です: トークンへのアクセスを制限し、リリースの決定をログし、各変更後に結果を検証してください。
変更記録を保存してください。
__CAPGO_KEEP_0__の変更記録にコミットまたはリリースIDを保存し、変更の理由を追加してください。ロールアウトが予期せずに停止した場合、ポリシーをバンドルとデプロイメント時間と比較できます。
Capgoは組織ごとにサブスクリプションで請求され、14日間の無料試用期間が用意されています。1回の購入ではありません。試用期間を利用してリリースワークフローをテストしたいチームに適したモデルです。試用期間を利用して、1つのチャンネルを設定し、1回のポーズテストを実行し、1つのロールバックパスを検証してください。
1つのコマンドで更新を公開できます。安全なワークフローは、チャンネルを確認し、採用を追跡し、ロールバックパスを残すものです。
FAQ
Capgoの自動ポーズ最小試行数とは何ですか?
Capgoの自動ポーズ最小試行数は、自動ポーズポリシーが作用する前に必要な最小インストールと失敗試行数を設定します。サンプルサイズゲートであり、失敗したインストールの割合ではありません。低い値では早く反応しますが、証拠に依存する可能性があります。高い値ではチャンネルに時間を与え、結果を集めます。
Capgoで自動ポーズ最小試行数を設定する場所はどこですか?
OTA バンドルの配信チャンネルで値を設定します。 Capgo ダッシュボード、CLI、またはパブリック API を使用し、保存されたフィールドを確認するためにチャンネルを再読み込みします。 チャンネル名を確認してください。 生産環境が有効なときにテストチャンネルを編集すると、生産ロールアウトに影響しません。
安全な最小試行値は何ですか?
安全な値はチャンネルサイズ、デバイスの組み合わせ、ネットワークの品質、リリースリスクに依存します。 制御されたテストチャンネルでは小さな閾値を使用し、広範な生産ロールアウトでは大きな閾値を使用します。 既知のグループから始めて試行の量を観察し、観察された行動に基づいて調整します。
最小試行値に到達すると、リリースが常に停止されることはありませんか?
いいえ。 Capgo 最小試行値に到達すると、ロールアウトが自動停止の対象となるようになりますが、他のポリシー条件も考慮されます。 失敗信号、信頼度設定、チャンネル状態、アップデーターフローは結果に影響を与える可能性があります。 安全なバンドルをテストしてから生産環境で使用するのを待ってください。
自動停止はロールバック計画を置き換えることはできますか?
いいえ。 自動停止はさらなる露出を停止または制限するのに対し、ロールバックは利用可能な場合にユーザーを知られているバンドルに移動させるものです。 両方のコントロールをテストしてください。 また、OTA ロールバックはインストール済みアプリが持っていないネイティブ機能を追加することはできません。
結論
チャンネルごとに最小試行回数の値を設定するのではなく、習慣に従わない。小規模なテストロールアウトから始め、停止とロールバックのパスを検証し、CI/CDで承認された設定を自動化する。ワークフローをテストしたい場合は、Capgoで1つのチャンネルと1つの制御されたバンドルを試して、ロールアウトを拡大する前に拡大する。
