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