試行回数の閾値が低すぎると、健全なOTAロールアウトが一時停止される可能性があります。高すぎると、不良なバンドルが多くのデバイスに配信されてしまう恐れがあります。Capgo Auto-Pause の Minimum Attempts この設定は、Capgo がチャネルを一時停止するのに十分なインストール数と失敗データを持っているかどうかを制御します。以下の手順に従って慎重に設定し、テストして、リリースフローに接続してください。
目次
- ステップ 1: Minimum Attempts が何を制御するかを理解する
- ステップ2: Capgoで自動一時停止の設定を見つける
- ステップ 3: 安全な Minimum Attempts 値を選ぶ
- ステップ 4: チャネルベースのロールアウトで Auto-Pause をテストする
- ステップ 5: 試行回数、アナリティクス、自動ロールバックを監視する
- ステップ 6: CI/CD で設定を自動化する
- よくある質問
- まとめ
ステップ 1: Minimum Attempts が何を制御するかを理解する
この Auto-Pause の Minimum Attempts この値は、一時停止ルールが動作する前に Capgo が必要とする最小サンプル数を設定します。これは失敗上限ではなくゲートです。この設定により、Capgo はロールアウトを判断する前に、十分なアップデート試行が蓄積されるまで待機します。
1 回の試行には、デバイスが bundle をインストールしようとする行為が含まれることがあります。試行は成功することも失敗することもあります。実際の結果は、アップデートパス、アプリの状態、updater の設定によって異なります。そのため、この値はロールアウト規模を踏まえて解釈すべきです。
Capgo のチャネルリファレンスでは、次のように説明していますauto-pause-min-attemptsauto-pause が有効になるまでの、インストールと失敗の試行回数の合計の最小値です。このフィールドは CLI リファレンスでは文字列として表されるため、使用するコマンドまたは API が期待する形式で値を指定してください。以下を確認できます: Capgo チャネルの CLI フィールド 稼働中のチャネルを変更する前に。
この設定は「最小限の証拠」ルールと考えてください。値を1にすると、最初の試行が記録された時点で反応する可能性があります。小規模な内部テストでは役立ちますが、1回のネットワーク不良にも反応してしまいます。値を大きくすると、ロールアウトが有用なサンプルを集める時間を確保できます。
試行回数とユーザーを区別する
「試行回数」は「ユニークユーザー数」とは異なります。1台のデバイスがアップデートを再試行する場合もあれば、1人のユーザーが複数のデバイスでアプリを実行する場合もあります。アナリティクスのビューでは、自社のプロダクト指標とは異なる形でイベントが集計されることもあります。
数値を決める前に、この閾値で何を保護したいかを書き出してください。壊れた JavaScript bundle を早期に検出したい場合は、小規模な制御チャネルでは低い値で十分です。広範な本番リリースを保護したい場合は、1台のデバイスや一時的な障害に基づく判断を避けるために、十分な試行回数が必要です。
- プライベートなテストチャネルでは、小さな閾値を使用してください。
- チャネルにネットワークやデバイス種別が混在している場合は、大きな閾値を使用してください。
- 一時的な障害で誤って一時停止が発生した場合は、閾値を上げてください。
- 検知が遅れるコストが、誤った一時停止のコストを上回る場合のみ、閾値を下げてください。
Auto-pause はロールアウトを停止するためのものです。bundle のレビュー、デバイスでのテスト、明確なロールバック計画の代わりにはなりません。閾値はリリースプロセス内の一つの制御要素として扱ってください。
重要なポイント: Minimum attempts は、Capgo の auto-pause ポリシーが動作する前に、ロールアウトの証拠として必要な量を決めます。
ステップ 2: Capgo で Auto-Pause 設定を見つける
設定するには Capgo auto pause minimum attempts の値を設定するには、まず bundle を配信するチャネルを見つけてください。Auto-pause はロールアウト制御に属するため、アプリ全体のアップデータ設定を変更しても、意図したチャネルポリシーが変更されない場合があります。
Capgo ダッシュボードから開始するか、チームがすでに使用しているチャネルコマンドと API パスを使用してください。編集する前にチャネル名を確認してください。テストチャネルと本番チャネルの名前が似ている場合があり、正しい値でも誤ったチャネルに設定すればリリースインシデントの火種になります。
チャネル設定で自動一時停止フィールドを探してください。関連フィールドには、最小試行回数の値や信頼度設定が含まれる場合があります。変更レビューでは、これらのフィールドをまとめて確認してください。最小サンプル数は、Capgo がロールアウトを判断してよいタイミングを示します。信頼度の値は、一時停止が起きる前にシグナルがどれだけ強くなければならないかに影響します。
監査可能なパスを通じて値を設定してください
すばやく制御された変更が必要で、チームがダッシュボードでの変更を記録している場合は、ダッシュボードを使用してください。設定をリリーススクリプトで管理する場合は、CLI を使用します。より広範なデプロイシステムの一部としてサービスがチャネルポリシーを管理している場合は、公開されている API を使用してください。
どの方法を選ぶ場合でも、まず古い値を記録してください。チャネル名、bundle バージョン、ロールアウト状態、新しい値を同じ変更レコードに保存します。これにより、後でチャネルが一時停止した際に明確な答えが得られます。
API 主導のワークフローでは、Capgo が公開 API を通じてチャネルリソースを公開します。この Capgo チャネル API ドキュメント が、ローカルスクリプトから推測するのではなく、フィールド名やリクエストの形式を確認するのに最適な場所です。
値を編集する際は、フィールドの仕様に従って整数を入力してください。パーセント記号（%）は含めず、小数も使用しないでください。ツールが設定をJSONとして保存する場合は、キーの綴りを正確に保ち、現在の Capgo リファレンスに示されている文字列形式を維持してください。
変更を確定する
保存後、再度チャネルを確認してください。コマンドが成功したからといって、意図したフィールドが変更されたと決めつけないでください。返されたチャネルデータまたはダッシュボードの値を確認してください。
次に、3つの質問を確認してください：
- 設定は意図したチャネルで変更されましたか？
- チャネルは依然として意図した bundle を指していますか？
- ロールアウトは実行中、一時停止中、完了のいずれですか？
値が表示されない場合は、そこで停止してください。権限、フィールドのスペル、チャネル識別子を確認します。保存状態を検証せずに成功を報告するデプロイスクリプトは信頼しにくいです。
ステップ 3: 安全な Minimum Attempts 値を選ぶ
ロールアウトの規模とリスクに基づいて、Capgo の自動一時停止の最小試行回数を設定してください。すべてのアプリに安全な数値はありません。適切な閾値は、ポリシーに十分な証拠を与えつつ、不良な更新を早期に検出できるようにします。
有用な情報を得られる最小のグループから始めます。プライベートチャネルには、既知のアプリバージョンを持つ内部デバイスが含まれる場合があります。本番チャネルには、古いデバイス、不安定な接続、数日に一度しかアプリを開かないユーザーが含まれる場合があります。これらのグループは、デフォルトで同じ閾値を共有すべきではありません。
シンプルな判断ルールを使用する
失敗パターンが意味を持つまでの試行回数を尋ねる。テストチャネルのデバイス数が少ない場合、高い閾値はテスト期間中に到達しない可能性があります。本番チャネルが数分で多くの試行を受ける場合、非常に低い閾値は短いネットワーク問題後にリリースを一時停止する可能性があります。
以下の場合、低い値を設定してください:
- チャネルがプライベートである場合。
- バンドルが高リスクの機能を変更する場合。
- 段階的テスト中に迅速なフィードバックが必要な場合。
- リリース直後にすべての失敗をチームが確認できる場合。
以下の場合、高い値を設定してください:
- チャネルが幅広いデバイス構成に対応している場合。
- ユーザーが不安定なネットワーク経由で接続する場合。
- アプリの1日あたりの起動頻度が低い場合。
- 短い障害が多くの誤検知失敗を生み出す可能性がある場合。
既知の問題を隠すために閾値を使用しないでください。バンドルが必須のネイティブプラグインで失敗する場合、リリースを自分で一時停止し、原因を修正してください。最小試行設定では、互換性のないバンドルを安全にすることはできません。
閾値とロールアウト規模を組み合わせる
まず小さな内部チャネルにリリースするケースを想定します。チームが自動停止が作動する前に複数のインストール結果を確認できるように、閾値を設定できます。バンドルがその段階を通過したら、より大きなサンプルサイズを反映した閾値を持つ広いチャネルに移行します。
このアプローチにより、本番環境のポリシーが極小のサンプルに反応することを避けつつ、最初のシグナルを迅速に取得できます。また、設定を調整する明確な場所が得られます。ロールアウトが失敗した後にではなく、チャネルに合わせて閾値を変更してください。
リリース記録の横にその値を追跡します。なぜその値を選んだのか、何が変われば変更するのか、誰がその変更を承認できるのかを記録してください。インシデント中に停止したチャネルを目にしたチームメンバーが、素早く文脈を把握する必要がある場合に重要になります。
プロのヒント: 制御されたチャネルから始め、その試行回数を記録し、推測ではなく観察されたロールアウトの挙動に基づいて本番環境の閾値を調整してください。
ステップ 4: チャネルベースのロールアウトで Auto-Pause をテストする
本番環境で依存する前に、チャンネル上でauto-pauseをテストしましょう。チャンネルがあればテストの範囲を区切れます。特定のグループにbundleを送信し、attemptが増えていく様子を監視して、ポリシーが閾値に達したときに何が起きるかを確認できます。
まず、本番リリースと混同しないよう識別できるテスト用bundleを作成します。codeの変更は安全に保ってください。テストの目的はリリース制御を検証することであり、アプリに別の問題を生むことではありません。
次に、少人数のテストデバイスをそのチャンネルに割り当てます。各デバイスに期待どおりのnative appバージョンが入っているか確認してください。OTA codeですべてのnativeの不一致を修正できるわけではないため、誤ったバイナリが動いているデバイスがあるとテスト結果の判断が難しくなります。
bundleをチャンネルに公開します。可能な限り通常のCapgoデプロイフローの1コマンドで行い、bundle IDとchannel IDはリリースログに残しておきましょう。インシデント発生時にターミナルのスクロールバック履歴だけに頼るのはやめてください。
pause経路のテスト
失敗したattemptを安全に発生させる方法が必要です。テスト専用のbundleを使うか、チームが承認した制御された失敗条件を利用してください。auto-pauseが機能するか確認するためだけに、本番bundleを壊すのは絶対にやめてください。
次の流れを確認してください：
- チャンネルがテスト用bundleを指している。
- デバイスがupdate指示を受信する。
- analyticsビューにattemptが表示される。
- 最小attempt数に達する。
- ポリシー条件を満たしていれば、失敗シグナルによってチャンネルがpauseする。
5番目のステップは重要です。minimum attempts の値に達すると、auto-pause の条件を満たす可能性があります。ただし、すべてのロールアウトがその正確な回数で停止するわけではありません。他のポリシーフィールドや観測された結果が結果に影響を与える可能性があります。
リカバリーもテストしてください
一時停止後、ユーザーが受け取る内容を確認してください。失敗した bundle が選択されたままになっているか、新しいデバイスがそれを停止しているか、以前の安全な bundle がロールバック用に利用可能かを確認します。回答は updater と channel の設定に依存するため、推測せずアプリのログで検証してください。
その後、誰かが失敗をレビューした後にのみ、既知の正常な bundle で再開してください。失敗が不良な build から来た場合は、新しい bundle を作成してください。同じ artifact を再び push して、次の試行が異なる動作をするのを期待するだけにはしないでください。
テスト結果を文書化してください。閾値、デバイス数、失敗条件、一時停止時間、復旧アクションを含めてください。これにより、一度きりのテストを再現可能なリリースチェックに変えることができます。
ステップ 5: 試行回数、アナリティクス、自動ロールバックを監視する
モニタリングは、Capgo の自動一時停止最小試行回数が正常なロールアウトを見ているのか、壊れたものを見ているのかを教えてくれます。失敗動作の横にある試行回数を監視してください。文脈のないカウントは、早すぎる一時停止や、拡大している問題の見逃しにつながる可能性があります。
Capgo Observe を使用して、更新アクティビティとロールアウトのステータスを確認します。 Capgo Observe ドキュメント アップデート情報の確認やauto-pauseの設定を行うエリアです。リリース序盤、特にbundleが起動時のcodeやアプリのコアフローを変更する場合は、dashboardを開いたままにしてください。
シグナルを組み合わせて判断する
まず試行回数の合計を見ます。次に失敗数と時間的なパターンを確認してください。安定してインストールが成功し続ける推移と、特定のbundleが有効になった直後に失敗が急増するパターンは明確に異なります。
可能であれば、デバイスとアプリバージョンの詳細も確認してください。失敗が特定のnativeバージョンに集中している場合、OTA bundleに新しいバイナリが必要な可能性があります。すべてのバージョンで失敗している場合は、bundle自体かアップデートサービスの経路を調べてください。
ネットワーク障害はノイズになり得ます。短時間の障害では、codeの不具合がなくても失敗が発生することがあります。そのため、しきい値は信頼性ポリシーと人によるレビューのプロセスと組み合わせて運用すべきです。Auto-pauseは影響の拡大を止められますが、すべての失敗を説明できるわけではありません。
自分のフローでロールバックが何を意味するかを理解する
ロールバックは、影響を受けたユーザーを動作が確認されているリリースに戻すか、問題のあるリリースがそれ以上のデバイスに届くのを止めるものです。必要な機能が欠けているnativeバイナリを修復することはできません。また、OTA bundleがすでに実行したデータマイグレーションを元に戻すこともできません。
本番利用の前に、テストチャンネルでロールバック経路を確認してください。どのbundleが安全と見なされるかを検証し、一時停止中にデバイスがオフラインになった場合の動作を確認します。その後、オンコールエンジニアが見つけられる場所に復旧手順を書いてください。
Capgo の ロールバックドキュメント 利用可能なロールバック制御をチャンネルプランにマッピングするのに役立ちます。結果はupdaterのバージョンやリリース設定によって変わる可能性があるため、ドキュメントに記載された動作を基準にしてください。
インシデント発生時、障害パターンが明確ならまず一時停止してください。その後、ログとバンドルの変更を確認します。既知の不良リリースが広がり続けるのを放置するより、数分かけて影響の拡大を防ぐ方が管理しやすいことが多いです。
ステップ 6: CI/CD で設定を自動化する
設定がチャネルごとに変わる場合は、リリースワークフローに Capgo の自動一時停止の最小試行回数の値を設定してください。自動化すれば手動によるズレはなくなります。選択したしきい値も code のレビューで確認できるようになります。
チャネルポリシーはシークレットと分けて管理してください。チャネル名、ロールアウト段階、最小試行回数はバージョン管理された設定に置けます。API のトークンは CI/CD のシークレットストアに保管してください。チャネル設定がすでにあるからといって、トークンをリポジトリにコミットしないでください。
リリースジョブは明確な順序に従うべきです：
- Webバンドルをビルドします。
- テストを実行し、ネイティブ互換性を確認します。
- バンドルをアップロードします。
- ターゲットチャネルを設定または確認します。
- 最小試行回数を適用します。
- 保存されたチャネル状態を検証します。
- 公開するか、ロールアウトを進めます。
デプロイシステムが対応していれば、dry-runやレビュー工程を活用してください。レビューでは、本番ステップを実行する前にbundle identifier、channel、threshold、rollout actionが表示されるべきです。
検証をジョブの一部として組み込む
API または CLI コマンドの完了後、再度channelの状態を取得してください。返された値が期待する設定と一致しない場合は、ジョブを失敗させます。これにより、誤ったchannel ID、拒否されたフィールド、部分的な更新を検知できます。
環境変数は、CIジョブにリリース設定を渡す一般的な方法です。これを使えば、ソースファイルにシークレットを記述することなく、channel名やthresholdを読み取れます。変数名は分かりやすく保ち、デプロイ前に必ずバリデーションを行ってください。
例えば、ワークフローでは次のような設定が必要になる場合があります：
CAPGO_CHANNELターゲットとなるchannel用CAPGO_MIN_ATTEMPTS承認済みのthreshold用CAPGO_BUNDLE_IDアップロードされたbundle用
これらの名前はワークフロー上の慣習であり、Capgo のフィールド名ではありません。これらを CLI や API の実際のフィールドに一箇所でマッピングしてください。そうすれば、将来の変更がレビューしやすくなります。
より詳細なセキュリティチェックについては、CI/CDパイプラインにおけるOTAアップデートの保護に関する Capgo のガイダンスを確認してください。重要な習慣はシンプルです。トークンのアクセス権限を制限し、リリースの決定をログに記録し、変更のたびに結果を検証することです。
変更記録を残す
thresholdをコミットIDまたはリリースIDと共に保存してください。変更理由も記録しておきます。もしrolloutが予期せず一時停止した場合、ポリシーとbundle、およびデプロイ時刻を比較して原因を特定できます。
Capgo は組織単位のサブスクリプションで課金され、買い切りではなく14日間の無料トライアルが付きます。このモデルは、通常のデリバリープロセスに組み込む前にリリースワークフローを試したいチームに向いています。トライアルでは作業を絞りましょう。チャネルを1つ設定し、一時停止テストを1回実行し、ロールバック経路を1つ検証します。
1つのコマンドでアップデートを公開できます。より安全なワークフローは、チャネルを確認し、導入状況を追跡し、ロールバック経路を残すものです。
よくある質問
Capgo の auto pause minimum attempts とは何ですか？
Capgo の auto pause minimum attempts は、auto pause ポリシーが動作する前に必要なインストール試行回数と失敗試行回数の最小値を設定します。これは失敗インストールの割合ではなく、サンプルサイズのゲートです。低い値は早く反応しますが、根拠が少なくなる可能性があります。高い値にすると、チャネルが結果を収集する時間を長く確保できます。
Capgo で auto pause minimum attempts はどこで設定しますか？
OTA バンドルを配信するチャネルで値を設定します。Capgo ダッシュボード、CLI、または公開 API を使い、チャネルを再取得して保存されたフィールドを確認します。まずチャネル名を確認してください。本番がアクティブな状態でテストチャネルを編集しても、本番のロールアウトは変わりません。
安全な minimum attempts の値はどれくらいですか？
安全な値は、チャネルサイズ、デバイス構成、ネットワーク品質、リリースリスクによって変わります。管理されたテストチャネルでは小さめのしきい値を使います。広範な本番ロールアウトでは大きめのしきい値を使います。既知のグループから始め、その試行量を監視し、実際の挙動に基づいて調整してください。
minimum attempts の値に達すると、必ずリリースは一時停止されますか？
いいえ。Capgo の最小試行回数に達すると自動一時停止の対象になりますが、他のポリシー条件も重要です。失敗シグナル、信頼度設定、チャネルの状態、アップデータフローが結果に影響します。本番環境で依存する前に、安全なバンドルで完全な一時停止パスをテストしてください。
auto-pause はロールバック計画の代わりになりますか？
いいえ。自動一時停止はさらなる露出を停止または制限しますが、ロールバックは利用可能な場合、ユーザーを既知の正常なバンドルへ移動させます。両方の制御をテストしてください。また、OTAロールバックでは、インストールされたアプリにないネイティブ機能を追加できないことを覚えておいてください。
まとめ
最小試行回数は習慣ではなく、チャネルごとに設定してください。小さなテストロールアウトから始め、一時停止とロールバックのパスを確認し、承認された設定をCI/CDで自動化します。ワークフローをテストしたい場合は、ロールアウトを拡大する前に、1つのチャネルと1つの制御されたバンドルで Capgo を試してください。
