Capgoの低い試行数のしきい値は、健康的なOTAロールアウトを停止させることができます。高いものは、悪いバンドルが多くのデバイスに到達することを許します。Capgo __CAPGO_KEEP_0__の自動停止試行数の最小値 Capgoがインストールと失敗データを十分に収集してチャンネルを停止できるようになったときに、Capgoの自動停止試行数の設定はどのように制御されるかを理解する必要があります。Capgoの設定に注意して、テストして、リリースフローに接続するには、以下の手順を実行してください。
目次
- ステップ 1: 最小試行数が制御するものを理解する
- ステップ 2: Capgoで自動停止設定を探す
- ステップ 3: 安全な最小試行数の値を選択する
- ステップ 4: チャンネルベースのロールアウトで自動停止をテストする
- ステップ 5: 試行数、分析、自動ロールバックを監視する
- ステップ 6: CI/CDで設定を自動化する
- FAQ
- まとめ
ステップ 1: 最小試行回数の制御を理解する
この 自動停止最小試行回数 最小試行回数の値は、Capgo の停止ルールが作用する前に必要なサンプル数を設定します。ゲートであり、失敗の制限ではありません。この設定は、Capgo に十分なアップデート試行が存在するまで待つように指示します。
試行は、デバイスがバンドルをインストールしようとするときに発生します。試行は成功または失敗する可能性があります。アップデートパス、アプリの状態、アップデート設定によって結果が決まります。そのため、この値はロールアウトのサイズを考慮して読む必要があります。
Capgo のチャネル参照ではauto-pause-min-attemptsas the minimum number of install plus fail attempts before auto-pause can take effect. The field is represented as a string in the CLI reference, so keep the value in the format expected by the command or API you use. You can review the インストールと失敗の試行の最小数として表現しています。Capgo の参照では、文字列として表現されるため、コマンドまたは CLI を使用するときに値を保持するようにしてください。Capgo チャネル CLI フィールドを確認する前に、ライブチャネルを変更することはできません。 この設定は、最小証拠規則として考えることができます。値が 1 の場合、最初の記録された試行後に反応する可能性があります。これは、非常に小規模な内部テストの場合に役立ちますが、1 つの悪いネットワークセッションに反応する可能性もあります。より大きな値を使用すると、ロールアウトに時間を与え、有用なサンプルを収集することができます。
ユーザー間の試行を分離する
ステップ 1: 最小試行回数の制御を理解する
試行はユニークなユーザーと同じではありません。1台のデバイスはアップデートを繰り返す可能性があります。1つのユーザーは複数のデバイスでアプリを実行する可能性があります。アナリティクスビューも、ユーザーの製品メトリクスとは異なる方法でイベントをグループ化する可能性があります。
数値を選択する前に、保護する閾値の目標を書き留めてください。目標は、早期に破損したJavaScriptバンドルを捕捉することである場合、制御されたチャネルでは小さな値を使用できます。目標は、広範なプロダクションリリースを保護することである場合、十分な試行回数を確保して、1台のデバイスまたは短いダウンタイムに基づく決定を避ける必要があります。
- プライベートテストチャネルでは、小さな閾値を使用してください。
- 混合ネットワークとデバイスの種類を持つチャネルでは、大きな閾値を使用してください。
- 短いダウンタイムが誤った停止を引き起こした場合、閾値を上げてください。
- 誤った停止のコストが遅い検出のコストよりも高くなった場合にのみ、閾値を下げてください。
自動停止はロールアウトを停止させるべきですが、バンドルレビュー、デバイステスト、明確なロールバック計画を置き換えるべきではありません。閾値を1つのリリースプロセスの制御として扱ってください。
重要なポイント: ロールアウト証拠の Capgo が自動停止ポリシーが作用する前に必要とする最小試行回数を制御します。
ステップ2: Capgoの自動停止設定を探してください。
自動停止設定を設定するには Capgo 自動停止最小試行値、まず配布チャンネルを検索してください。 Auto-pauseはロールアウト制御と関連しています。 したがって、App全体のアップデート設定を変更しても、期待どおりのチャネルポリシーが変更されない可能性があります。
Capgo ダッシュボードから始めて、またはチームがすでに使用しているAPI パスを使用してチャネルコマンドを実行してください。 チャンネル名を確認する前に、編集を開始しないでください。 テストチャンネルと実稼働チャンネルは似た名前を持つ可能性があり、正しい値が誤ったチャンネルに設定されている場合、リリースのインシデントが待ち受けていることになります。
チャンネル設定で自動停止フィールドを探してください。 関連フィールドには、最小試行値と信頼性設定が含まれる場合があります。 変更レビューで、関連フィールドを一緒に保管してください。 最小サンプルは、Capgo がロールアウトを判断するときの基準を示します。 信頼性値は、停止が発生する前に必要な信号の強さに影響します。
設定値を、検証可能なパスを通じて設定してください。
ダッシュボードを使用する場合は、迅速な制御された変更が必要な場合、チームはダッシュボードの変更を記録します。 設定値がリリーススクリプトに属する場合は、CLI を使用します。 サービスがより広範な展開システムの一部としてチャネルポリシーを管理する場合は、パブリックAPI を使用します。
どちらのパスを選択しても、元の値をキャプチャしてください。 チャンネル名、バンドルバージョン、ロールアウト状態、新しい値を同じ変更レコードに保存してください。 これにより、チャンネルが後で停止した場合に、明確な答えが得られます。
API ドライブされたワークフローでは、Capgo はパブリックAPI を通じてチャンネルリソースを公開します。 Capgo チャネル API ドキュメント は、フィールド名とリクエストの形状を確認するための正しい場所です。ローカルスクリプトから推測するのではなく。
値を編集するときは、フィールドが数値を求めるので、整数を入力してください。パーセント記号を追加しないでください。小数点を使用しないでください。ツールがJSON形式で設定を保存する場合、キーのスペルを正確に保持し、現在の Capgo リファレンスで示されている文字列形式を維持してください。
変更を確認してください。
保存した後、チャネルを再度読み取ります。成功したコマンドが意図したフィールドが変更されたことを意味するわけではありません。返されたチャネルデータまたはダッシュボード値を確認してください。
次に、3つの質問をします。
- 意図したチャネルで設定が変更されたかどうか?
- チャネルはまだ、意図したバンドルに指しているか?
- ロールアウトは、停止中、または完了したか?
値が表示されない場合は、そこで止めます。権限、フィールドのスペル、チャネル識別子を確認してください。保存された状態を確認しない deployment スクリプトは、信頼できません。
ステップ 3: 安全な最小試行回数の値を選択してください
Choose the Capgo auto pause minimum attempts value from the size and risk of the rollout. There is no safe number for every app. The right threshold gives the policy enough evidence while still detecting a bad update early.
最小のグループから始めましょう。内部デバイスと既知のアプリバージョンを含むプライベートチャンネル、または古いデバイス、弱い接続、および数日おきにアプリを開くユーザーを含むプロダクションチャンネルがあります。デフォルトでは、これらのグループは同じ閾値を共有してはなりません。
シンプルな決定ルールを使用しましょう。
失敗パターンが何かを意味するまで何回試行する必要があるかを尋ねましょう。テストチャンネルに数台のデバイスしかない場合、テスト期間中に閾値が達成される可能性は低くなります。プロダクションチャンネルでは、数分以内に多くの試行が受信されるため、短いネットワーク問題の後すぐにリリースを停止するために、閾値を非常に低く設定する必要があります。
以下の場合、閾値を下げてください。
- チャンネルがプライベートである場合。
- バンドルが高リスクの機能を変更する場合。
- ステージドテスト中には速いフィードバックが必要です。
- リリース後すぐにすべての失敗を検査できるチームがいる場合。
以下の場合、閾値を上げてください。
- チャンネルが幅広いデバイスをサポートする場合。
- ユーザーが不安定なネットワークを通じて接続する場合。
- アプリの日常開放頻度が低い場合。
- A short outage may cause many false failures.
Known problems should not be hidden by the threshold. If a bundle fails on a required native plugin, pause the release yourself and fix the cause. A minimum-attempt setting cannot make an incompatible bundle safe.
Threshold and rollout size should be paired.
Suppose you release to a small internal channel first. You might choose a threshold that lets the team see several install results before auto-pause can act. Once the bundle passes that stage, move it to a wider channel with a threshold that reflects the larger sample.
This approach keeps the first signal fast without asking the production policy to react to a tiny sample. It also gives you a clear place to adjust the setting. Change the threshold with the channel, not after the rollout has already failed.
Track the value beside the release record. Write down why you chose it, what would make you change it, and who can approve that change. This matters when a team member sees a paused channel during an incident and needs context quickly.
プロのヒント: コントロールチャネルから始め、試行回数を記録し、実行結果から観察したロールアウトの挙動に基づいて生産閾値を調整するのではなく、推測に頼るのではなく。
Step 4: Channel-Based RolloutのAuto-Pauseテスト
Test auto-pause on a channel before you depend on it in production. A channel gives you a boundary for the test. You can send a bundle to a known group, watch attempts rise, and confirm what happens when the policy reaches its threshold.
最初は、ライブリリースと混同しないように識別できるテストバンドルを作成してください。codeの変更を安全に保ちます。テストはリリースの制御を証明する必要がありますが、2番目のアプリ問題を生み出さないようにしてください。
次に、チャンネルにテストデバイスの小さなグループを割り当てます。各デバイスが期待どおりのネイティブアプリバージョンを持っていることを確認します。OTAcodeはネイティブの不一致をすべて修正することはできません。したがって、間違ったバイナリを実行しているデバイスは、テストを読み取るのが難しくする可能性があります。
チャンネルにバンドルを公開します。可能な限り、通常の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 を使用して、更新アクティビティとロールアウトのステータスを検査できます。 code Observe のドキュメント
OTA デプロイメントの分析、更新試行、自動ロールバックの監視
最初に試行回数を確認してください。次に、失敗回数と時間パターンを確認してください。成功したインストールの連続的な流れは、1つのバンドルが有効になった後の一時的な失敗のバーストとは異なります。
利用可能な場合、デバイスとアプリバージョンの詳細を確認してください。失敗が1つのネイティブバージョンに集中している場合、OTAバンドルは新しいバイナリが必要である可能性があります。失敗がすべてのバージョンにわたる場合、バンドル自体または更新サービスパスを検査してください。
ネットワーク障害はノイズを生じる可能性があります。短時間の障害は、codeの欠陥ではなく失敗した試行を生み出す可能性があります。そのため、信頼性ポリシーと人間のレビュープロセスとともに閾値が機能することを確認してください。自動停止は露出を止めることができますが、すべての失敗を説明することはできません。
ロールバックとは何かを理解してください。
ロールバックは、影響を受けたユーザーを知られている良好なリリースの方に向かって戻すか、悪いリリースがさらにデバイスに到達するのを止めることを意味します。ネイティブバイナリが必要な機能を欠いている場合、修復することはできません。また、OTAバンドルが実行したデータ移行を元に戻すこともできません。
生産環境で使用する前に、テストチャンネルでロールバックパスを確認してください。安全とみなされるバンドルを確認してください。デバイスがオフラインの場合に何が起こるかを確認してください。次に、オンコールエンジニアが見つけることができる回復手順を書きましょう。
Capgoの ロールバックドキュメント は、利用可能なロールバックコントロールをチャンネル計画とマッピングするのに役立ちます。ドキュメントされた動作を参照してください。結果はアップデータバージョンとリリース設定によって異なる可能性があります。
インシデントの際、明らかな失敗パターンが見つかったら、まず停止してください。次にログとバンドル変更を確認してください。数分間の停止は、悪いリリースが広がるのを許すことよりも管理しやすいです。
ステップ 6: CI/CD で設定を自動化する
リリースワークフローに Capgo の自動停止最小試行回数値を設定し、チャンネルごとに設定値が変化するようにしてください。自動化により、手動のずれがなくなるだけでなく、選択した閾値が code のレビューで明確に表示されます。
チャンネルポリシーとシークレットを分離してください。チャンネル名、ロールアウトステージ、最小試行回数値はバージョン管理された構成に置き換えられます。 API のトークンは、CI/CD のシークレットストアに残してください。チャンネル設定がすでに存在する場合でも、リポジトリにトークンをコミットしないでください。
リリースジョブは、明確な順序で進みます:
- ウェブバンドルをビルドします。
- ネイティブ互換性のテストとチェックを実行します。
- バンドルをアップロードします。
- ターゲットチャンネルを設定または確認します。
- 最小試行回数値を適用します。
- 保存されたチャンネル状態を検証します。
- リリースまたはロールアウトを進めます。
デプロイシステムがサポートする場合は、dry-runまたはレビューステージを使用してください。レビューでは、バンドル識別子、チャネル、閾値、ロールアウトアクションを表示する必要があります。プロダクションステップが実行される前にこれらの情報が表示されるようにしてください。
検証をジョブに組み込んでください。
APIまたはCLIコマンドが完了した後、チャネル状態を再度取得してください。返された値が予想どおりの構成と一致しない場合はジョブを失敗させます。これにより、間違ったチャネルID、却下されたフィールド、部分的な更新をキャッチできます。
環境変数は、CIジョブにリリース設定を渡す一般的な方法です。ジョブはチャネル名または閾値を読み取ることができますが、ソースファイルにシークレットを置く必要はありません。変数名を明確にし、デプロイ前に検証してください。
例えば、ワークフローでは次のようになります:
CAPGO_CHANNELターゲットチャネルに対して。CAPGO_MIN_ATTEMPTS承認された閾値に対して。CAPGO_BUNDLE_IDアップロードされたバンドルに対して。
その名前はワークフローコンビネーションであり、Capgoフィールド名ではありません。CLIまたはAPIフィールドに正確にマップしてください。将来の変更を簡単にレビューできるようにしてください。
より深いセキュリティチェックのために、CI/CD PipelinesにおけるOTA更新のセキュリティについてCapgoのガイダンスをレビューしてください。重要な習慣は単純です: トークンへのアクセスを制限し、リリース決定をログし、各変更後に結果を検証してください。
変更記録を保持してください。
閾値をコミットまたはリリースIDとともに保存してください。変更の理由を追加してください。ロールアウトが予期せずに停止した場合、ポリシーとバンドル、そしてデプロイ時間を比較できます。
Capgo は組織ごとにサブスクリプションで請求され、14日間の無料試用期間が付いており、1回の販売購入ではありません。 そのモデルは、リリースワークフローをテストしたいチームに適しています。 試用期間を集中して行うようにしてください: 1 つのチャネルを設定し、1 回の停止テストを実行し、1 つのロールバックパスを検証してください。
1 つのコマンドでアップデートを公開できます。 チャネルを確認し、採用を追跡し、ロールバックパスを残す安全なワークフローが望ましいです。
FAQ
Capgo の自動停止最小試行数とは何ですか?
Capgo の自動停止最小試行数は、自動停止ポリシーが作用する前に必要な最小のインストールと失敗試行数を設定します。 これは、失敗したインストールの割合ではなく、サンプルサイズのゲートです。 低い値では早く反応しますが、証拠に依存する可能性があります。 高い値では、チャネルに結果を収集する時間を与えます。
Capgo の自動停止最小試行数をどこで設定しますか?
Capgo ダッシュボード、CLI、またはパブリック API を使用して、OTA バンドルのチャネルを編集し、保存されたフィールドを確認します。 チャンネル名を確認してください。 テストチャンネルを編集すると、生産チャンネルがアクティブな場合、生産ロールアウトに影響しません。
安全な最小試行数の値は何ですか?
安全な値はチャンネルサイズ、デバイスの混合、ネットワークの品質、リリースリスクに依存します。 制御されたテストチャンネルでは、小さな閾値を使用し、広範な生産ロールアウトでは、大きな閾値を使用します。 既知のグループから始めて、試行数の量を観察し、観察された行動に基づいて調整してください。
リリースが最小試行値に到達することは、常にリリースを停止させることになるかどうか?
No. Reaching the Capgo minimum attempts value makes the rollout eligible for auto-pause, but other policy conditions still matter. Failure signals, confidence settings, channel state, and the updater flow can affect the result. Test the full pause path with a safe bundle before relying on it in production.
自動停止はロールバック計画の代替となるか
No. Auto-pause stops or limits further exposure, while rollback moves users toward a known-good bundle when that path is available. Test both controls. Also remember that an OTA rollback cannot add a native capability that the installed app does not have.
Conclusion
Set the minimum attempts value per channel, not by habit. Start with a small test rollout, verify the pause and rollback paths, then automate the approved setting in CI/CD. If you want to test the workflow, try Capgo with one channel and one controlled bundle before expanding the rollout.
