回滚

虽然 Capgo 的实时更新允许您快速向用户交付改进和修复,但在某些情况下您可能需要回滚到应用的先前版本。也许新更新引入了意外的严重问题,或者您想在修复时恢复特定更改。

Capgo 提供了几种方法来管理渠道的构建并控制用户收到的应用版本,包括手动回滚选项和自动安全机制。

自动回滚保护

Capgo 包含内置的安全机制,以保护您的用户免受损坏更新的影响。如果在调用 notifyAppReady() 方法之前发生 JavaScript 错误,插件将自动回滚到先前的工作版本。

当下载并应用新更新时,Capgo 期望您的应用在可配置的时间范围内调用 notifyAppReady() 以确认更新成功加载。此方法表明:

如果由于 JavaScript 崩溃或严重错误而未调用 notifyAppReady(),Capgo 将:

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

// 在应用成功初始化后调用此方法
await CapacitorUpdater.notifyAppReady()

这种自动保护有助于确保即使您不小心推送了损坏的更新,您的用户也不会被困在无法正常工作的应用中。

您可以通过在 Capacitor 配置中设置 appReadyTimeout 来配置 Capgo 等待调用 notifyAppReady() 的时间:

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

appReadyTimeout 值以毫秒为单位指定。默认超时通常为 10 秒,但您可以根据应用的初始化要求调整此值。如果您的应用由于复杂的初始化过程而需要更长的加载时间,您可能需要增加此值。

每次上传新构建并将其分配给渠道时,Capgo 都会保留这些构建的历史记录。如果您需要恢复特定更新,可以选择这些先前的构建之一重新部署到渠道。

回滚 UI 界面

回滚的主要方法是通过回滚界面,该界面位于 Capgo 控制台中查看渠道时的第 4 个选项卡(历史记录)。此选项卡提供渠道所有可用构建的全面视图,允许您轻松选择并恢复到任何先前的版本。

要使用历史记录选项卡进行回滚:

作为第二种方式,您还可以通过点击第一个选项卡中渠道构建历史记录中任何构建旁边的王冠图标直接进行回滚:

回滚后,配置为监听更新渠道的设备将在下次检查更新时收到先前的构建。回滚的构建将被视为新更新,因此通常的更新流程和条件适用。

如果您想在调查问题时暂时停止渠道上的更新,可以从其当前构建取消链接渠道。

要取消链接渠道:

一旦渠道被取消链接,它将不会分发任何新更新。配置到该渠道的设备将保持在其当前构建上,直到渠道再次链接到构建。

如果您发现更新有问题但还不确定要回滚到哪个构建,这很有用。取消链接渠道可以让您有时间调查,而不会推送进一步的更新。

在更严重的情况下,您可能希望将渠道上的所有设备恢复到最初与应用原生二进制文件打包的 Web 构建。这被称为”内置包”。

要在渠道上强制使用内置包:

当您强制使用内置包时,配置到该渠道的所有设备将在下次更新检查时恢复到原始打包的 Web 构建。无论它们当前使用的是什么构建,都会发生这种情况。

这是一个比恢复到特定先前构建更激进的回滚选项,因为它会丢弃自应用上次发布到应用商店以来发布的所有实时更新。

为了快速捕获问题并最小化有问题更新的影响,重要的是要有监控发布和响应问题的计划。

一些策略包括:

通过结合仔细监控和快速管理有问题更新的能力,您可以提供持续改进的应用体验,同时最大限度地减少对用户的干扰。