Cloud Defaultを変更する Capgo routes brand-new devices right away. Existing installs may stay on their old channel until they check in again, which explains many cases where a Capgo cloud default channel is not updating devices.
デバイスが新しいチャネルに自動的にルーティングされるため、既存のインストールは古いチャネルに留まることがある。これが、デバイスがCloud Defaultチャネルを更新しない多くのケースを説明する。
順序に従ってチェックを実行する。デバイスの割り当てを確認することから始め、アプリのビルド、同期状態、ロールアウトルール、ログ、ロールバック設定を調べる。
- 目次
- ステップ 1: デフォルトチャネルに割り当てられているデバイスを確認する
- ステップ 2: アプリ、ネイティブランタイム、更新の互換性を確認する
- ステップ 3: デプロイが実際にデフォルトチャネルに到達したことを確認する
- ステップ 4: デバイス側のログを確認し、最新の同期を強制する
- ステップ 5: ロールアウトルール、バージョンゲート、自動ロールバックを確認する
- Step 7: Default チャンネルを古くしない
- FAQ
- まとめ
Step 1: デバイスがデフォルトチャンネルに割り当てられていることを確認する
目的は、現在デバイスのチャンネルを決定するルールを特定することです。Cloud Default は、すでにデバイスが割り当てられている場合にのみ適用されます。
Capgo ダッシュボードを開き、影響を受けるデバイスを検査します。現在のチャンネル、アプリID、バージョン、最後のチェックイン時間を確認します。期待どおりのアップデートを受けたデバイスと比較すると、問題がすぐに解決することがよくあります。
チャンネル選択は順序に従います。強制チャンネルは優先されます。次に、API ダッシュボードまたはデバイスのオーバーライドが来ます。アプリによって設定されたローカルチャンネルが次に来ます。次に、Capgo がネイティブアプリの設定をチェックします。Cloud Default はデフォルトです。defaultChannelnative app config に設定されている Cloud Default は、デフォルトの設定です。
__CAPGO_KEEP_0__ アップデーター デバッグ ガイドを使用します。
Capgo Capgo updater debugging guide __CAPGO_KEEP_0__
次に、Capacitor の構成を確認してください。一般的なセットアップでは、次のようなチャネルが含まれます:
const config = { plugins: { CapacitorUpdater: { defaultChannel: 'production' } }
}このフィールドは任意です。値を入れない場合は、デバイスは Cloud Default を継承できます。生産用ビルドでは、チャネルルーティングは Capgo Cloud 内に残ります。値を入力する場合は、実際にデプロイするチャネルと一致することを確認してください。
現在、ローカルオーバーライドをアプリケーション code 内で探してください。setChannel()デバイスが正常なルーティングに戻すには、ローカル値をクリアしてください。デバイスのチャネル割り当てを削除するプラグインメソッドを使用するか、アプリを再インストールしてクリーンなテストを行うことができます。
Clear that local value when the device should return to normal routing. Use the plugin method that removes the device’s channel assignment, or remove the code that sets the channel and reinstall the app for a clean test.
Cloud Default が変更された場合でも、デバイス、またはローカルチャネル、またはアプリの割り当てが強い場合は、代わることはできません。 ステップ 2: アプリ、ネイティブランタイム、更新の互換性を確認する
ステップ 2: アプリ、ネイティブ ランタイム、およびアップデートの互換性を確認
目的は、インストール済みのアプリがアップロードしたバンドルを受け入れることができることを証明することです。正しいチャネルでも、ネイティブランタイムが互換性がない場合はアップデートをデバイスに送信できません。
アプリ ID で始めましょう。デバイスにインストールされているアプリは、プロジェクトでアップロードしたバンドルのアプリの同一性を使用する必要があります。アプリの同一性が一致しない場合、デバイスは間違った Capgo アプリをチェックします。
native runtimeバージョンとバンドルの互換性のルールを比較してください。Capgo Live Updateは、JavaScript、CSS、ウェブアセットを変更できます。Live Updateは、nativeプラグインを追加したり、nativeプロジェクトcodeを変更したりすることはできません。nativeの変更は、storeビルドの新しいバージョンが必要です。
native runtimeをウェブcodeの枠として考えます。新しいバンドルがインストール済みのアプリにないnativeAPIを要求している場合、Capgoはそのバンドルを適用しないようにします。まず、互換性のあるnativeバージョンをビルドしてアップロードし、そのバンドルをテストしてください。
インストール済みのアプリのバージョンとプラットフォームを確認してください。AndroidバンドルをAndroidでテストし、iOSバンドルをiOSでテストしてください。また、チャンネルがバージョンゲートを使用している場合、バンドルが正しいアプリバージョンをターゲットしていることを確認してください。
変更後defaultChannelプロジェクトのルートからsyncコマンドを実行してください。
npx cap syncこのステップでは、更新された構成をnativeプロジェクトにコピーします。syncせずに編集すると、nativeアプリは古いチャンネル設定に留まります。古いnativeプロジェクトからビルドすると、同じ結果が再生されます。capacitor.configクリーンなテストのために、syncした後、新しいアプリをビルドしてください。古いバイナリがインストールされている電話に依存しないでください。キャッシュされたローカルチャンネル状態を削除するには、古いバイナリをアンインストールし、新しいビルドをインストールしてチャンネルを確認してください。
この
The Capgo アップデート動作ドキュメント __CAPGO_KEEP_1__
また、バンドルのネイティブバージョンゲートも確認してください。バンドルは正しいチャンネルに存在している場合でも、デバイスの最小アプリバージョンと一致しない限り利用できません。リリースの詳細はダッシュボードで確認してください。
アプリがこれらのチェックを通過した場合、問題の範囲は狭まります。次の質問は、リリースが目的のチャネルに到達したかどうかです。
ステップ 3: デフォルトチャネルにデプロイが実際に到達したことを確認する
チャンネルでデバイスが解決するチャンネルにバンドルが存在することを確認するのが目的です。 1 つのチャンネルにバンドルをアップロードすることは、すべてのチャンネルで利用可能になることを意味しません。
CloudでCapgoチャンネルを開きます。 有効なバンドル、バンドルのバージョン、デプロイメント状態を確認します。 アプリが返す値とチャンネル名を比較します。 小さな差異を注意してください。production対決prodチャンネル名は完全に一致する必要があります。
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.
bundleの状態を確認してください。ダッシュボードではドラフトまたは非アクティブのリリースが表示されるかもしれませんが、デバイスでは利用できません。チャンネルがステージングロールアウトを実行している場合、影響を受けるデバイスはロールアウトのルールを満たしていない可能性があります。
1台のテストデバイスを使用します。明確な役割を与えます。例えば、1台のデバイスをテストチャンネルに固定し、もう1台のデバイスはCloud Defaultに残します。無害な変更をアップロードし、そのチェックインレコードを比較します。このテストでは、推測が排除されます。
CapgoのライブOTAエンジンは、Web層の変更用に設計されています。JavaScriptバンドル、CSS、またはアセットの更新を新しいストアレビューの待ちなしで動かすことができます。その速度は、デバイスがチェックするチャンネルにリリースが有効である場合にのみ実現します。
Cloud Defaultを直前に変更した場合は、デバイスのタイミングを思い出してください。新規インストールは新しいルートをすぐに使用します。既存のデバイスは、次のアップデートチェックを実行するときに通常スイッチします。アプリを閉じて再度開くことで、チェックをトリガーすることができますが、固定チャンネルを上書きすることはできません。
アプリ内で結果を確認してください。getChannel()アプリが起動または前景でチェックする場合、遅延が発生することを予想してください。チェックを実行する画面を開くのではなく、短いテストビルドで知られた起動パスにチェックを配置し、リリース前に余分なログを削除してください。
返されたチャンネルが正しいがバンドルが届かない場合は、互換性とロールアウトルールに進みます。返されたチャンネルが間違っている場合は、ステップ1に戻り、Cloud Defaultを上書きする割り当てをクリアしてください。
ステップ4: 強制的な最新同期とデバイス側のログの検査
about_how_step_label
目標は、古いローカル状態とサーバー側の配信問題を分離することです。最新のチェックインにより、新しい証拠が得られます。
最初に、デバイスがネットワークにアクセスできることを確認してください。アプリの成功したセッションは、アップデータがエンドポイントに到達できることを証明するものではありません。企業のフィルタリング、VPNルール、キャプティブゲートウェイ、または期限切れのセッションがアップデート要求をブロックする可能性があります。
次に、アプリを前面に移動してください。アップデータチェックが完了するのを待ってください。アプリがアップデートステータスイベントを公開している場合、現在のチャンネルとともにそのイベントをログに記録してください。アップデートが始まったことをのみログに記録するのではなく、必要なステージが何であるかを知る必要があります。たとえば、チャンネルが欠如している場合はルーティングに問題があることを示し、ネイティブランタイムまたはバージョンゲートに問題があることを示すのは互換性の拒否です。ダウンロードエラーはネットワークアクセスまたはバンドル要求に問題があることを示します。
Use Capgo’s device logs to find the first failed stage. The first error is usually more useful than the final “update failed” message. For example, a missing channel points to routing. A compatibility rejection points to the native runtime or version gate. A download error points to network access or the bundle request.
| 観察されること | 可能性のあるチェックポイント | 次のアクション |
|---|---|---|
| コンテキスト: Capgo Builder / ネイティブクラウドビルド製品ページ。役割: 短いUIラベルまたはナビゲーションアイテム。メッセージキー `native_build_builder_credit_next` (ネイティブビルドビルダークレジット次) | チェックインレコードがない | Confirm startup code, network access, and updater initialization |
| 起動時に確認する__CAPGO_KEEP_0__、ネットワークアクセス、およびアップデータの初期化 | アプリ内に間違ったチャンネルが存在する | 強い割り当てをクリアし、再度呼び出しgetChannel()再度 |
| 正しいチャネル、エラブルなバンドルなし | リリース状態またはバージョンゲートが配信をブロック | バンドル状態、アプリバージョン、チャネルルールを確認 |
| バンドルが見つかったが、インストールが拒否された | 互換性、署名、またはローカルストレージの問題 | 最初のデバイス側のエラーを読み取り、互換性のあるバンドルでテスト |
| インストールが完了したが、古いcodeがまだ実行中 | 新しいバンドルが読み込まれていない、またはアプリが前のバージョンで再起動 | リロードの動作、有効なバンドル状態、ロールバックイベントを確認 |
再インストールは有用なテストですが、証拠を変えるので注意。再インストールはローカルチャネル状態をクリアするため、現在のチャネルとログをキャプチャした後、またはそれ以前のテストを行う前に使用すること
再現性チェックのために、以下の値を1行のログに記録してください:
- App IDとネイティブアプリのバージョン
- 解決済みチャンネル
getChannel() - 最後のアップデートチェック時間
- サーバーから取得したバンドルバージョン
- インストールまたは拒否結果
小さな記録は、デバイスがテスターに属している場合に問題を再現することができない場合に役立ちます。また、CIチームに自動化されたsmokeテストの明確な信号を与えます。
公式のCapgo Capacitor アップデートソースリポジトリを使用して、プラグインAPIの動作を調べる必要がある場合に、特に、ローカルチャンネル変更とダッシュボードデバイス割り当ての差異に注意してください。
プロのヒント: 解決済みチャンネルをキャプチャする前に、クリアしないでください。そうすると、問題を解決した後、失敗の原因を説明するクレームを失ってしまいます。
ステップ5:ロールアウトルール、バージョンゲート、自動ロールバックを確認
目標は、Capgoが意図的にバンドルを抑制または逆転したかどうかを確認することです。更新が欠けている場合、安全ルールが正常に機能している場合があります。
チャンネル設定を開いて、リリースに紐づいたすべてのルールを確認してください。 最小アプリバージョン、ロールアウト割合、デバイスフィルタ、リリースに紐づいた条件などを確認してください。 ルールに外れたデバイスは、チャンネルが正しい場合でも現在のバンドルに留まります。
バージョン形式も確認してください。Capgoは、リリースを比較するためにシーケンスバージョニングを使用します。 人間にとっては正しいように見えるバージョンゲートでも、エラーが発生した場合にアプリまたはバンドルが予想外の形式を使用している場合に異なる動作をする可能性があります。 また、ネイティブビルドとOTAリリースの両方で形式を統一してください。
次に、ロールバックの動作を確認してください。 健康チェックに失敗した場合に自動ロールバックがデバイスを前のバンドルに戻す可能性があります。 ダッシュボードでは、古いアクティブなcodeが表示され、期待するリリースは表示されますが利用できません。
疑わしいバンドルを削除するのを避けてください。 削除は有用な証拠を失います。 まず、バンドルバージョン、チャンネル、ロールアウト状態、ロールバックの理由を記録してください。 次に、リリースを一時停止するか、知られているバージョンを公開する決定を下してください。
リスクのある変更を使用する場合は、ステージチャンネルを使用してください。 小規模なテストグループにバンドルを送信してください。 アドプションとエラーのシグナルを監視してください。 リリースが予想どおり動作する場合にロールアウトを進めてください。 これにより、悪いウェブレイヤーチェンジがすべてのアクティブなデバイスに一度に到達するのを防ぐことができます。
Rollback only repairs code that OTA can change. If the failure comes from a missing native plugin or an incompatible native API, you need a new store build. Sending an older JavaScript bundle will not add the native piece that the app lacks.
ルールを検査するときは、3つの質問をします。
- このデバイスは、アプリバージョン条件を満たしていますか?
- デバイスはロールアウトグループ内にありますか?
- ヘルスチェックまたはマニュアルアクションによって古いバンドルに戻されましたか?
Capgoはここで役立ちます。同じチャンネルモデルは、ステージングリリースをサポートし、ロールバックを実行し、1つのワークフロー内で更新アクティビティを表示できます。ルールセットを小さくしてください。短いポリシーは、インシデント中に作成された例外のスタックよりも簡単に検証できます。
APIベースのチェックが必要な場合は、 Capgo 公開APIドキュメント デバイス、チャンネル、バンドルのリソースについての情報が記載されています。サーバー側のビューとアプリ側のレポートを比較すると、古いダッシュボードフィルターや、自動化によって作成されたデバイス割り当てを明らかにすることができます。
ロールバックはテストの代わりではありません。生産チャンネルに常に1つの知られている良好なバンドルを用意してください。
ステップ6：リアルタイム分析を使用して、正確な障害ポイントを特定する
目標は、「未更新」ということを１つの失敗として扱うのをやめることです。アナリティクスでは、デバイスがチェックインしなかったか、エラブルなバンドルを見つけたか、ダウンロード中に失敗したか、後でロールバックしたかなどを確認できます。
まず、影響を受けたデバイスグループから始めます。アプリバージョン、プラットフォーム、チャネル、バンドルバージョンでフィルタリングし、パターンを探します。１つの古いアプリビルドだけが失敗している場合、ネイティブ互換性ゲートが問題である可能性があります。１つのチャネルで全てのデバイスが失敗している場合、チャネルまたはデプロイメントを調べます。
採用度を時間とともに比較すると、リリース後はフラットラインが示唆されることがあります。これはルーティングまたはエラブル性の問題を示唆しています。上昇した後に下落した場合は、インストールエラーまたはロールバックを示唆しています。ゆっくりと上昇している場合は、デバイスがアプリを開いていない可能性があります。
タイムスタンプを慎重に使用してください。ダッシュボードのイベント時間はユーザーのローカル時間と異なる可能性があります。アップデートイベントをデバイスの最後のチェックイン時間と照合すると、テスターがアップデートが失敗したと言っている場合でも、実際にはアプリがチェックインしていなかった場合に役立ちます。
アナリティクスは、チャネル変更を安全にテストすることも助けます。１つの変数を１つずつ変更してください。バンドルを固定してルーティングをテストし、ルーティングを固定して新しいバンドルをテストします。両方を変更すると、データはどちらの変更が問題を解決したかを判断できません。
インシデントの場合、小さな証拠セットを保存してください:
- デバイスIDまたは内部テストラベル
- 解決済みチャネル
- ネイティブアプリバージョン
- 期待されるバンドルとインストールされたバンドル
- 最後のチェックイン時間
- ロールバックまたは拒否イベント
Capgoのリアルタイムビューは、CI/CDプロセスでアップデートを送信する場合に最も役立ちます。デプロイジョブはバンドルをアップロードし、監視ステップではテストデバイスが予定されているチャネルとバンドルを報告することを確認します。その結果、手動の苦情がリリースゲートに変わります。
リリースレコードと分析データを紐付けます。デプロイメントノートにコミットまたはビルドの参照を記載します。バンドルが類似したバージョンラベルを持つ場合、ビルド参照はどのcodeが実際に変更したかを教えてくれます。
Cloud Default変更後、既存のデバイスがすべて失敗した場合、さらに設定を変更する前に、次のチェックインを待ちます。新規インストールは有効なコントロールです。デバイスが古いローカル状態を持たない場合、デフォルトルートが機能するかどうかを教えてくれます。
ステップ7：デフォルトチャネルが古くなりそうになるのを防ぐ
目標は、ユーザーに影響を与える前にチャネルドリフトを視覚化することです。小さなリリースチェックリストは、繰り返しケースを防ぐことができます。
アプリケーション環境ごとに、ルーティングモデルを選択してください。生産環境では省略できます。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.
Putnpx cap syncデプロイ後、Smokeテストを追加してください。テストデバイスはアプリを起動し、
を呼び出します。getChannel()、期待されるバンドルを確認し、結果を記録する。OTAワークフローにおける検証はよく欠けている。アップロードだけでは、非常に少ない証拠しか示していない。
ローカルチャネルcodeを明確な機能フラグで後ろに置く。テストヘルパーが呼び出す場合setChannel()、生産用ビルドに間違って含まれないようにする。ローカルキャッシュはダッシュボードのオーバーライドとして表示されない可能性があるため、UIはすべての問題を捕捉できない。
このようなリリースチェックリストを使用する。
- アプリIDとネイティブバージョンを確認する。
- ターゲットチャネルを選択する。
- 指定されたチャネルにバンドルをアップロードする。
- バンドルが有効であることを確認する。
- デバイスのSmokeテストを実行する。
- 返されたチャネルを確認する。
getChannel(). - 採用を観察する前に、展開範囲を広げないようにする。
生産リリースのロールバック保護を維持する。デプロイ時に明確なチャネルやロールバック計画が欠けていることがよくある失敗パターンである。そうすると、チームは悪いバンドルを止める安全な方法が少なくなってしまう。
Capgo は組織ごとにサブスクリプションを使用し、14日間の無料試用期間が付いています。試用期間を、実際のアプリビルドでリリースフローをテストする機会として扱ってください。ただし、ダッシュボードをインスペクトするだけではありません。1 つのステージングデプロイ、1 つのロールバックテスト、1 つの自動チャネル確認を試してください。
セキュリティは同じチェックリストに含まれます。CI/CD トークンを保護すること、Cloud Default の変更を制限すること、ローカル スクリプトからプロダクション デプロイ クレデンシャルを除外することなどを行ってください。未承認のチャネル変更は、レビューした場合に古いデバイスのように見える可能性があります。
頻繁にリリースするチームでは、プロセスを面白くすることなく、デプロイを 1 つのコマンドで行い、1 つの知られているテスト デバイスを使用し、1 つの明確なチャネル規則を使用してください。トラッキング、採用、ロールバックを実行してください。
重要なポイント: 古いルーティングを防ぐには、構成を同期し、隠れたローカルオーバーライドを回避し、解決済みチャネルをテストし、ロールバックを準備してください。
FAQ
Why is the Capgo cloud default channel not updating existing devices?
なぜ __CAPGO_KEEP_0__ クラウド デフォルト チャネルは既存のデバイスを更新していないのですか?getChannel()アプリを前面に移動し、強い割り当てをクリアします。
クラウド デフォルト Capgo を変更すると、すべてのインストール済みアプリが変更されるのですか?
No、Cloud Default を変更しても、インストール済みのすべてのアプリのチャネルは即座に書き換えられません。新しいデバイスでは、新しいデフォルトをすぐに使用できますが、既存のインストールではチェックインする必要があります。チェックインした後でも、より強いチャネルルールまたはローカルオーバーライドが適用されている場合はチャネルを変更しません。
npx cap sync では、Capgo チャネル変更のために何が行われるのですか?
npx cap syncCapgoは、更新されたCapacitor設定をネイティブプロジェクトにコピーします。設定を変更するとdefaultChannel__CAPGO_KEEP_0__ で setChannel は、__CAPGO_KEEP_0__ にデバイスオーバーライドを作成しますか?
セットチャンネルはデバイスのオーバーライドをCapgoに作成しますか。
No,setChannel()Capgo は、OTA バンドルを通じてネイティブ __CAPGO_KEEP_1__ を更新できますか?getChannel().
CapgoはCapgoをOTAバンドルを通じて、ネイティブのcodeを更新できますか。
No, Capgo OTA updates apply to web-layer code such as JavaScript, CSS, and assets. A native plugin, permission, or native API change needs a new store build. If the bundle expects native code that the installed app lacks, the update may be rejected even when the channel is correct.
Conclusion
, バンドルをネイティブランタイムと照合し、デバイスログを確認することから始めましょう。次に、__CAPGO_KEEP_0__ で小規模な post-deploy テストを追加し、npx cap syncCapgo でgetChannel()と確認します。
