コンテンツにスキップ

ロールバック

Capgo のライブ アップデートにより、ユーザーに迅速に改善と修正を提供できますが、特定のバージョンに戻す必要がある場合があります。新しいアップデートが予期せぬ重大な問題を導入したり、特定の変更を修正するために時間がかかる場合など、状況によっては、以前のバージョンのアプリに戻す必要があります。

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

自動ロールバック保護

自動ロールバック保護

Capgoには、ユーザーを破損した更新から保護するための組み込みの安全機構が含まれています。JavaScriptエラーが発生した場合、Capacitorはエラーをキャッチし、ユーザーにエラーを表示せずに、エラーが発生した前のバージョンにフォールバックします。 notifyAppReady() メソッドが呼び出されたとき、プラグインは自動的に前の正常に動作していたバージョンに戻します。

自動ロールバックのしくみ

「自動ロールバックのしくみ」

更新がダウンロードされ適用された後、Capgoはアプリが呼び出すことを期待します。 notifyAppReady() within a configurable timeframe to confirm that the update loaded successfully. This method signals that:

  • バンドルは批判的エラーなしでJavaScriptを読み込めました。
  • アプリの基本機能は正常に動作しています。
  • 安全に保管できます。

もし notifyAppReady() JavaScriptのクラッシュまたは重大なエラーにより呼び出されない場合、Capgo は以下のようになります。

  1. アップデートが正しく初期化されていないことを検出しました。
  2. 自動的に前の正常に機能するバンドルに戻します。
  3. アップデートを問題があると判断した場合は、再度適用されるのを防ぐために失敗とマークする。
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__ の設定ファイルの appReadyTimeout の値はミリ秒単位で指定されます。デフォルトのタイムアウトは通常 10 秒ですが、アプリの初期化要件に応じて調整することができます。アプリの初期化プロセスが複雑で時間がかかる場合、値を増やすと良いでしょう。

Capgo は、毎回アップロードした新しいビルドとチャンネルに割り当てたときに、ビルドの履歴を保持します。特定のアップデートを元に戻す必要がある場合、以前のビルドのいずれかを選択してチャンネルに再デプロイできます。

__CAPGO_KEEP_0__ ダッシュボードのチャンネルを表示し、4 番目のタブ(履歴)に移動すると、ロールバックインターフェイスが表示されます。このインターフェイスは、チャンネルのすべての利用可能なビルドを一目で確認し、以前のバージョンに簡単に戻ることができます。

The primary way to roll back is through the rollback interface, which is located in the 4th tab (History) when viewing a channel in the Capgo Dashboard. This tab provides a comprehensive view of all available builds for the channel, allowing you to easily select and revert to any previous version.

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

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

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

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

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

  5. ビルド履歴でロールバックしたいビルドを選択する

  6. このビルドにロールバックすることを確認する

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

ビルド履歴の任意のビルドの隣にあるクラウンアイコンをクリックしてロールバックする

  1. __CAPGO_KEEP_0__
  2. __CAPGO_KEEP_1__ __CAPGO_KEEP_2__
  3. __CAPGO_KEEP_3__

__CAPGO_KEEP_7__

__CAPGO_KEEP_8__

__CAPGO_KEEP_9__

__CAPGO_KEEP_10__

__CAPGO_KEEP_11__

  1. チャンネルに移動するには、Capgo ダッシュボードにアクセスしてください。

  2. 現在のビルドの横の「リンク解除」ボタンをクリックしてください。

  3. チャンネルをリンク解除することを確認してください。

チャンネルがリンクされると、デバイスは現在のビルドに留まります。チャンネルが再びビルドとリンクされるまで、デバイスは新しい更新を配信しません。

更新に問題が見つかった場合、まだ戻りたいビルドを決定できていない場合、チャンネルをリンク解除することは便利です。問題を調査する時間を与えますが、さらに更新を配信しないようにします。

強制インストール

「強制インストール」

より深刻な状況では、すべてのデバイスを、元のネイティブバイナリと一緒にパッケージ化されたアプリのウェブビルドに戻したい場合があります。これは「ビルトインバンドル」と呼ばれます。

チャンネルに強制インストールするには、

  1. チャンネルに移動するには、Capgo ダッシュボードにアクセスしてください。

  2. 「ビルトインバンドル」ボタンをクリックしてください。

  3. 強制インストールを確認してください。

When you force the built-in bundle, all devices configured to that channel will revert back to the original packaged web build on their next update check. This happens regardless of what build they’re currently on.

This is a more aggressive rollback option than reverting to a specific previous build, as it discards all live updates released since the app was last published to the app stores.

To catch issues quickly and minimize the impact of problematic updates, it’s important to have a plan for monitoring your releases and responding to problems.

Some strategies include:

  • Crash reports and user feedback should be monitored immediately after releasing an update.
  • Phased rollouts or a staged channel system should be used to test updates on a smaller group before wide release.
  • A clear decision process should be established for when to roll back, unlink, or force the built-in bundle, and who has the authority to do so.
  • ユーザーに問題と解決策について伝える

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