Fix Capgo Default Channel Not Updating Devices

クラウドデフォルトを変更する Capgo 新しいデバイスはすぐにルートされる。既存のインストールは再接続するまで、古いチャンネルに留まることがあります。これが、Capgo クラウドのデフォルトチャンネルがデバイスを更新しない多くのケースを説明するのです。

順序に従ってチェックを実行します。デバイスの割り当てを確認し、次にアプリのビルド、同期状態、ロールアウトルール、ログ、ロールバック設定を検査します。

目次

• ステップ 1: デフォルトチャンネルに割り当てられているデバイスを確認する
• ステップ 2: アプリ、ネイティブランタイム、更新の互換性を確認する
• ステップ 3: 実際にデフォルトチャンネルに到達したデプロイを確認する
• ステップ 4: デバイス側のログを検査するために新しい同期を強制する
• ステップ 5: ロールアウトルール、バージョンゲート、自動ロールバックを確認する
• ステップ 6: 実時間分析を使用して、正確なエラーの原因を特定する
• ステップ 7: デフォルトチャンネルが古くなってしまうのを防ぐ
• FAQ
• 結論

Step 1: __CAPGO_KEEP_0__ に割り当てられているデバイスを確認する

目的は、現在どのルールがデバイスのチャンネルを決定しているかを調べることです。Cloud Default は、強い割り当てがすでにデバイスを占有していない場合にのみ適用されます。

Capgo ダッシュボードを開いて影響を受けたデバイスを検査します。現在のチャンネル、アプリID、バージョン、最後のチェックイン時間を確認します。期待どおりのアップデートを受け取ったデバイスと比較すると、問題がすぐに解決することがよくあります。

チャンネルの選択は順序に従います。強制チャンネルは優先されます。次にダッシュボードまたは API のデバイスのオーバーライドが来ます。アプリによって設定されたローカルチャンネルが次に来ます。その後 Capgo がネイティブアプリの設定をチェックします。Cloud Default はデフォルトです。defaultChannelその順序は、デバイスがダッシュボードエラーなしでCloud Defaultが変更された場合に無視できることを意味します。たとえば、テストビルドがまだ以前のテストからローカルチャンネルを保持している場合、アプリはそのローカル値を使用し続けます。その値をクリアするまでです。

__CAPGO_KEEP_0__ のアップデータデバッグガイドを使用します。

解決されたチャンネルが空白または予期せぬ場合、__CAPGO_KEEP_0__ のアップデータデバッグガイドを参照してください。アプリが利用可能なデフォルトを持たず、デバイスがオーバーライドを持たない場合のケースをカバーしています。 次に、Capgo の構成を確認します。一般的なセットアップでは、次のようなチャンネルが含まれます。 このフィールドはオプションです。フィールドを省略すると、デバイスはCloud Defaultを継承できます。その場合、チャンネルルーティングは __CAPGO_KEEP_0__ Cloud内に残ります。フィールドを含める場合は、実際にデプロイしているチャンネルと一致する値を指定してください。

Capacitor

const config = { plugins: { CapacitorUpdater: { defaultChannel: 'production' } }
}

The field is optional. If you leave it out, the device can inherit the Cloud Default. That can work well for production builds because channel routing stays in Capgo Cloud. If you include it, make sure the value matches the channel you actually deploy to.

現在、codeアプリケーションでローカルオーバーライドを探してください。呼び出しsetChannel()ローカルキャッシュを変更します。バックエンドのデバイスオーバーライドを作成しないため、ダッシュボードではオーバーライドが表示されない場合がありますが、アプリはローカルチャネルを使用し続けます。

ローカル値をクリアして、デバイスが正常なルーティングに戻るようにします。デバイスのチャネル割り当てを削除するプラグインメソッドを使用するか、チャネルを設定するcodeを削除してアプリを再インストールして、クリーンなテストを行います。

重要なポイント: Cloud Defaultが変更された場合でも、強いデバイス、アプリ、またはローカルチャネル割り当てを置き換えることはできません。

ステップ 2: アプリ、ネイティブランタイム、更新の互換性を確認する

目的は、インストール済みのアプリがアップロードしたバンドルを受け入れることを証明することです。正しいチャネルでも、互換性のないネイティブランタイムではアップデートをデバイスに送信できません。

アプリ IDから始めます。デバイスにインストールされているアプリは、プロジェクトでアップロードしたバンドルのアプリの同一性を使用する必要があります。アプリの同一性が一致しない場合、デバイスは間違ったCapgoアプリをチェックし、チャネル問題のように見える可能性があります。

次に、ネイティブランタイムのバージョンとバンドルの互換性規則を比較します。Capgoライブアップデートでは、JavaScript、CSS、Webアセットを変更できますが、ネイティブプラグインを追加したり、ネイティブプロジェクトcodeを変更したりすることはできません。ネイティブの変更は、まだ新しいストアビルドが必要です。

native runtimeを想像してください。native runtimeはweb codeの枠組みです。新しいbundleがインストール済みのアプリにないnative APIを要求している場合、Capgoはそれを適用しないようにしてください。互換性のあるnativeバージョンをビルドしてアップロードし、そのbundleをテストしてください。

インストール済みのアプリのバージョンとプラットフォームを確認してください。Android bundleをAndroidでテストし、iOS bundleをiOSでテストしてください。また、チャンネルがバージョンゲートを使用している場合、bundleが正しいアプリバージョンをターゲットしていることを確認してください。

変更後defaultChannelプロジェクトのルートからsyncコマンドを実行してください。

npx cap sync

このステップでは、更新された構成をnativeプロジェクトにコピーします。syncせずに編集すると、nativeアプリは古いチャンネル設定に残ります。古いnativeプロジェクトから新しいビルドを実行すると、同じ結果が繰り返されます。capacitor.configクリーンなテストのために、syncした後、新しいアプリをビルドしてください。古いバイナリがインストールされている電話に依存しないでください。キャッシュされたローカルチャンネル状態を削除するために、古いアプリをアンインストールし、新しいビルドをインストールし、チャンネルを確認してください。

__CAPGO_KEEP_0__のアップデート動作ドキュメント

アップデートのタイミングを使用してください。アップデートのチェックが完了する前に、アプリを起動したり、フォアグラウンドに戻したりしてください。アップデートが失敗したと判断する前に、チェックを完了するようにしてください。 Capgo update behavior documentation __CAPGO_KEEP_0__のアップデート動作ドキュメント

__CAPGO_KEEP_1__

このチェックを通過したアプリは、問題の範囲が狭まったことになります。次の質問は、リリースが目的のチャンネルに到達したかどうかです。

ステップ 3: デフォルト チャンネルにデプロイが実際に到達したかどうかを確認する

目的は、デバイスが解決するチャンネルにバンドルが存在することを確認することです。1 つのチャンネルにバンドルをアップロードするだけでは、すべてのチャンネルで利用可能になるわけではありません。

Capgo Cloud でチャンネルを開き、有効なバンドル、バンドルのバージョン、デプロイの状態を確認します。チャンネル名をアプリが返した値と照合し、小さな差異を確認します。productionversusprod. Channel names must match exactly.

If you deploy through CI/CD, inspect the command output from the same job that uploaded the bundle. Confirm the app ID and channel passed to the CLI. A pipeline can finish with a successful upload while targeting a staging channel by mistake.

CI/CD を使用してデプロイする場合、同じジョブからコマンドの出力を確認します。アプリ ID とチャンネルが __CAPGO_KEEP_0__ に渡されたことを確認します。パイプラインは、間違ってステージング チャンネルをターゲットにした場合に成功したアップロードで終了する可能性があります。

次に、バンドルのステータスを確認します。ダフまたは非アクティブ リリースは、ダッシュボードに表示されるかもしれませんが、デバイスには利用できない可能性があります。チャンネルにステージド ロールアウトがある場合、影響を受けるデバイスはロールアウト ルールを満たしていない可能性があります。

CapgoのリアルタイムOTAエンジンは、ウェブ層の変更用に設計されています。JavaScriptのバンドル、CSS、またはアセットの更新を、ストアの新しいレビューの待ちなしで動かすことができます。そのスピードは、デバイスがチェックするチャンネルに、リリースがアクティブであるかどうかに依存します。

Cloudflareのデフォルトを直前に変更した場合は、デバイスのタイミングを思い出してください。新しいインストールでは、新しいルートをすぐに使用します。既存のデバイスは、更新チェックを実行するときに通常切り替わります。アプリを閉じて再度開くことで、チェックをトリガーすることができますが、固定チャンネルをオーバーライドすることはできません。

Now verify the result inside the app. CallgetChannel()アップデータが開始した後、ログを表示して、返されたチャンネルとアプリバージョン、バンドルバージョンを表示してください。この方法は、ダッシュボードでしか確認できない情報を表示するため、ダッシュボードでしか確認できない情報よりも有用です。

アプリが起動または前景でしかチェックを行わない場合は、遅延が発生する可能性があります。アップデータを開始しない画面を開くことでテストするのは避けてください。短期間のテストビルドを作成し、起動パスにチェックを追加し、リリース前に余分なログを削除してください。

返されたチャンネルが正しいが、バンドルが届かない場合は、互換性とロールアウトルールに進みます。返されたチャンネルが間違っている場合は、ステップ1に戻り、Cloud Defaultの割り当てをクリアしてください。

ステップ4: 強制的に最新のSyncを実行し、デバイス側のログを検査する

デバイス側の古いローカル状態とサーバー側の配信問題を分離することが目的です。最新のチェックインにより、新しい証拠が得られます。

デバイスはネットワークに接続されていることを確認してください。アップデートが成功した場合でも、エンドポイントにアクセスできることを証明するものではありません。企業のフィルタリング、VPNルール、キャプティブゲートウェイ、または期限切れのセッションはアップデートリクエストをブロックする可能性があります。

次に、アプリを前面に移動してください。アップデートチェックが完了するのを待ってください。アップデートステータスイベントを公開している場合は、そのイベントをログに記録してください。ただし、単に「アップデートが始まった」というログだけを記録してはいけません。アップデートが成功したかどうかを知る必要があります。アップデートが成功したかどうかを知るには、バンドルが見つかったかどうか、ダウンロードされたかどうか、検証されたかどうか、インストールされたかどうか、または拒否されたかどうかを知る必要があります。

Capgoのデバイスログを使用して、最初の失敗したステージを探してください。最初のエラーは、最終的な「アップデートが失敗しました」というメッセージよりも有用です。たとえば、チャネルが見つからない場合はルーティングに問題があることを示します。ネイティブランタイムまたはバージョンゲートに問題がある場合は、互換性の拒否を示します。ネットワークアクセスまたはバンドルリクエストに問題がある場合はダウンロードエラーを示します。

再インストールは有用なテストですが、証拠を変えるので注意。再インストールはローカルチャネル状態をクリアするため、現在のチャネルとログをキャプチャした後、またはそれ以前のテストを行う前に使用すること。

再現可能な確認のために、次の値を1行のログに記録してください。

• App ID とネイティブ アプリ バージョン
• 解決されたチャネルからgetChannel()
• 最後のアップデート チェック 時間
• サーバーから見つかったバンドル バージョン
• インストールまたは拒否結果

その小さな記録は、デバイスがテスターに属している場合に問題を要求することができない場合に役立ちます。また、CI チームに自動化されたスモーク テストの明確な信号を与えます。

公式の Capgo Capacitor アップデーター ソース リポジトリを使用して、プラグイン API の動作を調べる必要がある場合に、必要に応じてください。特に、ローカル チャネル変更とダッシュボード デバイス割り当ての差異に注意してください。

Pro Tip: 解決されたチャネルをキャプチャする前に、クリアしないでください。そうしないと、状態を修正して失った説明が原因の失敗のヒントを失います。

ステップ 5: ロールアウト ルール、バージョン ゲート、自動ロールバックを確認

目的は、Capgo が意図的にバンドルを保留したり逆転させたかどうかを確認することです。欠落した更新は、安全ルールが設計どおりに機能している場合に発生することがあります。

チャネル設定を開いて、すべてのリリースに付随するルールを確認してください。最小アプリ バージョン、パーセンテージロールアウト設定、デバイス フィルタ、リリースに結びついた条件を探してください。デバイスがルール外にある場合、チャネルが正しい場合でも、現在のバンドルに留まります。

バージョン形式も確認してください。Capgoは、リリースを比較するためにセマンティック バージョニングを使用します。アプリまたはバンドルが予想外の形式を使用している場合、人にとって正しそうに見えるバージョンゲートでも、異なる動作をする可能性があります。ネイティブ ビルドとOTAリリースの両方で、形式を一貫して維持してください。

次に、ロールバックの動作を確認してください。自動ロールバックは、失敗したヘルス チェック後にデバイスを前のバンドルに戻す可能性があります。ダッシュボードは、古いアクティブなcodeを表示し、期待どおりのリリースが存在するものの利用できない状態になります。

疑わしいバンドルを削除しないでください。削除は有益な証拠を消去します。まず、バンドルのバージョン、チャンネル、ロールアウト状態、ロールバックの理由を記録してください。次に、リリースを一時停止するか、知られているバージョンを公開するかを決定してください。

リスキーな変更を使用するには、ステージド チャンネルを使用してください。まず、小規模なテスト グループにバンドルを送信してください。採用とエラーのシグナルを監視してください。リリースが予想どおり動作するようになったら、ロールアウトを進めてください。このように、悪いウェブ層の変更がすべてのアクティブ デバイスに一度に到達するのを防ぐことができます。

ロールバックは、OTAが変更できるcodeのみを修復します。失敗がネイティブ プラグインの欠如または互換性のないネイティブAPIから来ている場合、新しいストア ビルドが必要になります。古いJavaScriptバンドルを送信すると、欠けているネイティブ部分を追加することはできません。

ルールを検査するときは、3つの質問をしてください:

• このデバイスは、アプリのバージョン条件を満たしているか?
• デバイスはロールアウト グループ内にあるか?
• ヘルス チェックまたは手動アクションによって、古いバンドルに戻されたか?

Capgoはここで便利です。同一のチャネルモデルは、ステージングリリースを実行し、ロールバックをサポートし、1つのワークフロー内で更新アクティビティを表示することができます。ルールセットを小さく保ちましょう。短いポリシーは、インシデント中に作成された例外のスタックよりも簡単に検証できます。

If API-based checks are required, the Capgoの公開APIドキュメント は、デバイス、チャネル、バンドルのリソースについての情報を提供しています。サーバー側のビューとアプリケーション側のレポートを比較することで、古いダッシュボードのフィルターや、自動化によって作成されたデバイスの割り当てを発見することができます。

ロールバックはテストの代わりではありません。生産チャネルに常に1つの知られている良好なバンドルを保管しておきましょう。

ステップ6：リアルタイム分析を使用して、正確な障害ポイントを特定する

障害を「更新されていない」という単一の障害として扱うのではなく、障害を止めることが目標です。分析は、デバイスがチェックインしなかったか、適切なバンドルを見つけることができなかったか、ダウンロード中に失敗したか、後でロールバックしたかを示すことができます。

まず、影響を受けたデバイスグループから始めましょう。アプリケーションバージョン、プラットフォーム、チャネル、バンドルバージョンでフィルタリングしてみましょう。パターンを探してみましょう。1つの古いアプリケーションビルドのみが失敗している場合、ネイティブの互換性ゲートが原因かもしれません。1つのチャネルですべてのデバイスが失敗している場合、チャネルまたはデプロイを調べる必要があります。

採用度を時間の経過と比較してみましょう。リリース後に平坦な線が示される場合、ルーティングまたはエリギビリティの問題が原因かもしれません。上昇後に下降する線は、インストールエラーまたはロールバックの可能性があります。ゆっくりと上昇する線は、デバイスがアプリケーションを開いていない可能性があります。

__CAPGO_KEEP_0__のタイムスタンプを慎重に使用してください。ダッシュボードのイベント時間は、ユーザーのローカル時間と異なる場合があります。アップデートイベントをデバイスの最後のチェックインと照合することで、実際にチェックインした前にアップデートが失敗したとテスターが言っている場合に役立ちます。

アナリティクスも、チャンネル変更を安全にテストするのに役立ちます。1つの変数を変更して、他の変数は変えずにテストしてください。バンドルは一定のままにして、ルーティングをテストしてください。次に、ルーティングは一定のままにして、新しいバンドルをテストしてください。両方を変更すると、どちらの変更が問題を解決したかを判断することができません。

インシデントの場合、次の小さな証拠セットを保存してください:

• デバイス識別子または内部テストラベル
• 解決済みチャンネル
• ネイティブアプリバージョン
• 予想バンドルとインストール済みバンドル
• 最後のチェックイン時間
• ロールバックまたは拒否イベント

Capgoのリアルタイムビューは、リリースプロセスがCI/CDを通じてアップデートを送信する場合に最も役立ちます。デプロイジョブはバンドルをアップロードし、監視ステップはテストデバイスが意図したチャンネルとバンドルを報告することを確認します。その結果、手動の苦情はリリースゲートに変わります。

アナリティクスデータをリリースレコードと紐付けしてください。コミットまたはビルド参照をデプロイメントノートに記載してください。バンドルが類似したバージョンラベルを持つ場合、ビルド参照はどのcodeが実際に動いたかを判断するのに役立ちます。

デバイスがCloud Defaultを変更した後、既存のデバイスがのみ失敗する場合は、次のチェックインを待ってから設定を変更しましょう。新規インストールは有効なコントロールです。デバイスが古いローカル状態を持たない場合、デフォルトルートが機能するかどうかを判断できます。

Step 7: Default Channel の古くなり方を防ぐ

ユーザーに影響する前にチャネルが古くなっていることを視覚化することが目標です。小規模なリリースチェックリストは、繰り返し発生する多くのケースを防ぐことができます。

各アプリ環境ごとにルーティングモデルを選択します。生産環境では、__CAPGO_KEEP_0__ を省略して Cloud がデフォルトのチャネルを制御することもできます。テストビルドでは、明示的なチャネルを設定することもできます。危険な設定は、古いローカルオーバーライド、古いネイティブ設定、そして誰も検証していない新しい Cloud のデフォルトです。defaultChanneland let Capgo Cloud control the default. For a test build, you may set an explicit channel. The dangerous setup is a mix of old local overrides, stale native config, and a new Cloud Default that nobody verifies.

構成変更後、ビルドが失敗するように設定します。Sync ステップが失敗した場合、ビルドが失敗するようにします。コマンドは簡単ですが、スキップすると昨日のチャネルが今日のネイティブバイナリに焼き付いてしまいます。npx cap syncデプロイ後にSmokeテストを追加します。テストデバイスはアプリを起動し、

を呼び出し、期待どおりのバンドルをチェックし、結果を記録します。バージョンアップロードだけでは、ほとんどのことを証明できません。getChannel()ローカルチャネル __CAPGO_KEEP_0__ を明確な機能フラグで保護します。テストヘルパーが呼び出す場合、生産ビルドが間違って含まれないようにします。ローカルキャッシュはダッシュボードオーバーライドとして表示されない可能性があるため、UI ですべての問題を検出することはできません。

Keep local channel code behind a clear feature flag. If a test helper callssetChannel()アプリIDとネイティブバージョンを確認します。

アプリIDとネイティブバージョンを確認します。

1. アプリIDとネイティブバージョンを確認します。
2. チャンネルを選択してください。
3. 指定したチャンネルにバンドルをアップロードしてください。
4. バンドルの有効性を確認してください。
5. デバイスのSmokeテストを実行してください。
6. 返されたチャンネルとgetChannel().
7. 拡大展開前に採用状況を確認してください。

生産リリースの場合、ロールバック保護を維持してください。 通常、リリースを実行する際に、明確なチャンネルやロールバック計画がなければ、チームは悪いバンドルを止めるための安全な方法が少なくなります。

Capgoは組織ごとにサブスクリプションを使用し、14日間の無料試用期間が付いています。 試用期間を、実際のアプリビルドでリリースフローをテストする機会として扱ってください。 ただし、ダッシュボードをインスペクトするだけではありません。 1回のステージングデプロイ、1回のロールバックテスト、1回の自動チャンネルチェックを試してください。

セキュリティも同じチェックリストに含めてください。 CI/CDトークンを保護してください。 Cloud Defaultを変更できるユーザーを制限してください。 生産リリースのクレデンシャルをローカルスクリプトから外してください。 不正なチャンネル変更は、レビューしたアクセスログまで、古いデバイスのように見えます。

頻繁にリリースするチームは、プロセスを面白くするのではなく、面白くしないでください。 1つのコマンドでデプロイしてください。 1つの知っているテストデバイスを使用してください。 1つの明確なチャンネルルールを使用してください。 トラッキング、採用、ロールバックを実行してください。

キータイクエイク: 古いルーティングを防ぐには、構成を同期し、隠れたローカルオーバーライドを避け、解決されたチャンネルをテストし、ロールバックを準備してください。

FAQ

なぜ、Capgoクラウドのデフォルトチャネルは、既存のデバイスを更新していませんか?

既存のデバイスは、次の更新チェックまで古いチャネルを保持する可能性があります。ローカルチャネル、ダッシュボードのオーバーライド、強制割り当ても、クラウドデフォルトよりも優先される可能性があります。デバイスの解決済みチャネルを確認し、getChannel()、強い割り当てをクリアし、アプリを前景にします。

Capgoクラウドデフォルトを変更すると、すべてのインストール済みアプリが変更されるのですか?

いいえ、クラウドデフォルトを変更すると、すべてのインストール済みアプリのチャネルを即座に書き換えるわけではありません。新しいデバイスはすぐに新しいデフォルトを使用できますが、既存のインストールはチェックインするまで変更されません。強いチャネルルールまたはローカルオーバーライドが適用されている場合も、変更されません。

npx cap sync が Capgo チャネル変更のために何をするのですか?

npx cap syncCapacitor の更新された構成をネイティブプロジェクトにコピーします。変更をスキップすると、次のネイティブビルドでも古いチャネル設定が含まれる可能性があります。プロジェクトルートからコマンドを実行し、ビルドしてインストールした新しいテストバイナリをビルドしてインストールしてください。defaultChannelsetChannel は __CAPGO_KEEP_0__ にデバイスオーバーライドを作成しますか?

Does setChannel create a device override in Capgo?

チャネルを変更するだけなので、バックエンドのデバイスオーバーライドを作成しません。__CAPGO_KEEP_0__ ダッシュボードでは、デバイスがオーバーライドされていると表示されない可能性があります。デバイスがデフォルトルーティングに戻る必要がある場合、ローカル割り当てをクリアし、結果を確認してください。setChannel()changes the channel stored locally by the app. It does not create a backend Device Override, so the Capgo dashboard may not show the device as overridden. Clear the local assignment when the device should return to default routing, then verify the result withgetChannel().

CapgoはcodeをOTAバンドルを通じて更新できますか?

CapgoのOTA更新はJavaScript、CSS、資産などのウェブ層のcodeに適用されます。ネイティブプラグイン、権限、またはAPIの変更には新しいストアビルドが必要です。バンドルがインストール済みアプリが欠けているcodeを期待している場合、チャネルが正しい場合でもアップデートは拒否される可能性があります。

まとめ

まず解決済みのチャネルから始めましょう。割り当てを確認し、実行し、npx cap sync、インストール済みアプリのネイティブランタイムとバンドルを検証し、デバイスのログを確認することから始めましょう。次に、ロールアウトルールを変更する前に、小規模なポストデプロイテストをCapgoで実行し、getChannel()を呼び出し、期待どおりのバンドルを確認します。