ロールバック

Capgoのライブ更新により、ユーザーに改善と修正を迅速に提供できますが、状況によっては、以前のアプリのバージョンに戻す必要があります。新しい更新が予期せぬ重大な問題を引き起こしたり、特定の変更を修正しながら修正に取り組む場合などです。

Capgoは、チャンネルのビルドを管理し、アプリのバージョンをユーザーが受け取るように制御する方法を複数提供します。これには、手動のロールバックオプションと自動的な安全機構も含まれます。

自動ロールバック保護

Capgoには、ユーザーを破損した更新から保護するための組み込みの安全機構が含まれます。JavaScriptエラーがメソッドが呼び出される前に発生した場合、プラグインは自動的に前の正常なバージョンにロールバックします。 notifyAppReady() 自動ロールバックのしくみ

「自動ロールバックのしくみ」のセクション

When a new update is downloaded and applied, Capgo expects your app to call notifyAppReady() __CAPGO_KEEP_0__は、JavaScriptエラーが発生する前にメソッドが呼び出されることを期待します。

• JavaScriptバンドルが重大なエラーなしでロードされたことを示します
• アプリの基本機能は正常に動作しています
• 更新は安全に保管できます

もし notifyAppReady() は、JavaScriptのクラッシュまたは重大なエラーのため呼び出されなかった場合、Capgoは:

1. 更新が正しく初期化されていないことを検出します
2. 自動的に前の正常に動作していたバンドルに戻ります
3. 問題のある更新を失敗としてマークして、再度適用されるのを防ぎます

ヒント

アプリの初期化の際に__CAPGO_KEEP_0__を呼び出すことを確認してください。 notifyAppReady() in your app’s initialization code after your core components have loaded successfully. This ensures the automatic rollback protection works as intended.

import { CapacitorUpdater } from '@capgo/capacitor-updater'

// Call this after your app has successfully initialized
await CapacitorUpdater.notifyAppReady()

この自動保護機能により、意図しない更新を誤ってプッシュした場合でも、ユーザーは機能しないアプリに巻き込まれません。

タイムアウトの設定

Capgoが呼び出されるまでの時間を設定するには、 notifyAppReady() を設定します。 appReadyTimeout Capacitorの設定:

{
  "plugins": {
    "CapacitorUpdater": {
      "appReadyTimeout": 10000
    }
  }
}

__CAPGO_KEEP_0__の値はミリ秒で指定されます。デフォルトのタイムアウトは通常10秒ですが、アプリの初期化要件に基づいて調整することができます。アプリの初期化プロセスが複雑な場合、初期化に時間がかかる場合はこの値を増やすことを検討してください。 appReadyTimeout 前のバンドルのロールバック

タイムアウトの設定

Every time you upload a new build and assign it to a channel, Capgo keeps a history of those builds. If you need to revert a specific update, you can select one of these previous builds to redeploy to the channel.

Capgo ダッシュボードでチャンネルを表示している場合、ロールバックの主な方法は、4 番目のタブ（History）にあるロールバックインターフェイスです。このタブでは、チャンネルに対して利用可能なすべてのビルドを一览表形式で表示し、以前のバージョンに簡単に戻ることができます。

History タブを使用してロールバックするには:

1. __CAPGO_KEEP_0__ ダッシュボードにログインする Capgo Dashboard.

2. ロールバックしたいチャンネルの名前をクリックする

3. チャンネルビューの 4 番目のタブ（History）に移動する

4. ビルド履歴でロールバックしたいビルドを探す

5. ロールバックしたいビルドを選択してチャンネルのアクティブビルドに設定する

6. ロールバックするビルドに確定する

7. 代替方法：クラウンアイコンを使用する

__CAPGO_KEEP_0__

As a second way, you can also roll back directly from the first tab by clicking the crown icon next to any build in the channel’s build history:

1. In the first tab of the channel view, find the build you want to revert to.
2. Click the crown icon next to that build to make it the active build for the channel.
3. Confirm that you want to roll back to this build.

Note

Rolling back to a previous build only affects the selected channel. If you have multiple channels (e.g. Production, Staging, etc.), you’ll need to repeat the rollback process for each affected channel.

After rolling back, devices configured to listen to the updated channel will receive the previous build the next time they check for an update. The rolled-back build will be treated as a new update, so the usual update flow and conditions apply.

Rolling back to a previous build only affects the selected channel. If you have multiple channels (e.g. Production, Staging, etc.), you’ll need to repeat the rollback process for each affected channel.

__CAPGO_KEEP_0__のチャンネルを一時的に停止したい場合は、問題を調査するためにチャンネルを現在のビルドから切り離すことができます。

チャンネルを切り離すには：

1. Capgo ダッシュボードに移動してチャンネルを選択します。

2. 現在のビルドの横の「切り離し」ボタンをクリックします。

3. 切り離しを確認します。

チャンネルが切り離された後は、デバイスは新しいアップデートを受信せずに、現在のビルドで動作を続けます。チャンネルが再びビルドとリンクされるまで、デバイスは現在のビルドで動作を続けます。

問題が発生したアップデートを特定するのに時間がかかり、どのビルドに戻したいのかがわからない場合は、この機能を使用できます。チャンネルを切り離すことで、問題を調査する時間を稼ぎながら、さらにアップデートを配布するのを防ぐことができます。

ビルトインバンドルを強制する

ビルトインバンドルは、元のネイティブバイナリと組み込まれたWebビルドです。このビルトインバンドルをすべてのデバイスに強制する必要がある場合もあります。

ビルトインバンドルを強制するには：

1. Capgo ダッシュボードに移動してチャンネルを選択します。

2. Built-in Bundle”ボタンをクリックしてください。

3. built-in bundleを強制することを確認してください。

built-in bundleを強制すると、チャンネルに設定されているすべてのデバイスは、更新チェックの次回以降、元のパッケージされたWebビルドに戻ります。これは、現在のビルドに関係なく、どのビルドでも発生します。

このオプションは、特定の前のビルドに戻るよりも、より強力なロールバックオプションです。なぜなら、最後にアプリをアプリストアに公開したときから、問題のないアップデートがすべて破棄されるからです。

注意

built-in bundleを強制する際には、すべてのデバイスに影響を与える可能性があるため、十分な注意を払ってください。影響を考慮し、進む計画を立ててからこのアクションを実行してください。

問題の発生を早期に検出し、問題のあるアップデートの影響を最小限に抑えるには、リリースを監視し、問題に応じて対応する計画を立てることが重要です。

問題の発生を早期に検出し、問題のあるアップデートの影響を最小限に抑えるには、リリースを監視し、問題に応じて対応する計画を立てることが重要です。

問題の発生を早期に検出し、問題のあるアップデートの影響を最小限に抑えるには、リリースを監視し、問題に応じて対応する計画を立てることが重要です。

• 問題の発生を早期に検出し、問題のあるアップデートの影響を最小限に抑えるには、リリースを監視し、問題に応じて対応する計画を立てることが重要です。
• フェーズドロールアウトまたはステージチャンネルシステムを使用して、広範なリリース前に小規模なグループでアップデートをテストする
• ロールバック、アンリンク、または組み込まれたバンドルを強制する際の明確な決定プロセスを持ち、権限を持つ者が誰であるかを明確にする
• ユーザーに問題と解決策について伝える

監視に注意を払い、問題のあるアップデートを迅速に管理できる能力を組み合わせると、ユーザーに最小限の混乱を与えながら、継続的に改善されるアプリの体験を提供できます。

ロールバックから続ける

ロールバックを使用している場合 ロールバック バージョン管理とロールバックを計画するために接続する バージョン目標 バージョン目標の実装詳細 アップデートの動作 Update Behaviorの実装詳細について bundle __CAPGO_KEEP_0__ Live Updatesの実装詳細について Capgo Live Updatesの製品ワークフローについて、 Capgo Live Updatesのロールバック戦略について Capacitor Live Updatesのロールバック戦略の実用的な背景について。 for the practical context in Rollback Strategies for Capacitor Live Updates.