跳过内容

回滚

Capgo的实时更新功能使您能够快速向用户提供改进和修复,但在某些情况下,您可能需要回滚到应用程序的前一个版本。例如,新更新可能引入了意想不到的关键问题,或者您可能希望在修复期间回滚特定更改。

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

Capgo内置了一个安全机制来保护用户免受更新中的错误影响。如果在方法被调用之前发生JavaScript错误,插件将自动回滚到上一个可用的版本。 notifyAppReady() method is called, the plugin will automatically roll back to the previous working version.

当下载并应用新更新时,Capgo 需要您的应用调用 notifyAppReady() 在可配置的时间框架内确认更新加载成功。该方法表示:

  • JavaScript 包装没有严重错误
  • 您的应用的核心功能正常工作
  • 更新是安全的

如果 notifyAppReady() is not called due to a JavaScript crash or critical error, Capgo will:

  1. __CAPGO_KEEP_0__ 将:
  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
}
}
}

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

__CAPGO_KEEP_0__ 回滚到之前的打包

回滚到之前的打包

每次您上传新的构建并将其assign到一个频道时,Capgo都会保存这些构建的历史。如果您需要回滚特定的更新,可以选择其中一个之前的构建并重新部署到频道中。

回滚UI界面

回滚主要通过回滚界面来实现,回滚界面位于Capgo控制台的第4个标签(历史)中。当您在Capgo控制台中查看频道时,这个标签提供了所有可用构建的全面视图,使您可以轻松选择并回滚到任何之前的版本。

通过历史标签回滚:

  1. 登录到 Capgo控制台.

  2. 导航到“频道”部分

  3. 点击您要回滚的频道的名称

  4. 在频道视图中,转到第4个标签(历史)

  5. 在构建历史中找到您要回滚的构建

  6. 选择该构建以将其设置为该频道的活动构建。

  7. 确认您想回滚到此构建。

备选方法:使用皇冠图标

标题:备选方法:使用皇冠图标

作为第二种方式,您也可以直接从第一个选项卡中回滚到构建,点击频道构建历史中的任何构建旁边的皇冠图标:

  1. 在频道视图的第一个选项卡中,找到您要回滚到的构建。
  2. 点击该构建旁边的皇冠图标以将其设置为频道的活动构建。 频道管理选项
  3. 确认您想回滚到此构建。

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

解除频道绑定的步骤是:

导航到__CAPGO_KEEP_0__控制台中的频道。

  1. Navigate to the channel in the Capgo Dashboard.

  2. 确认您要解除频道的绑定。

  3. 一旦频道解除了绑定,它就不会分发任何新更新。配置为使用该频道的设备将保持在其当前构建状态,直到频道再次与构建绑定。

这对于您已经确定了更新问题但尚未确定要回滚到哪个构建的情况非常有用。解除频道绑定可以为您提供调查的时间,同时避免推出进一步的更新。

强制内置捆绑包

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

强制内置捆绑到一个通道:

  1. 导航到Capgo控制台中的通道。

  2. 点击“内置捆绑”按钮。

  3. 确认您想强制内置捆绑。

当您强制内置捆绑时,所有已配置为该通道的设备将在下一次更新检查时重置回原来的打包Web构建。这无论它们当前的构建是什么都发生。

这比重置到特定之前的构建更具侵入性,因为它丢弃了自应用最后发布到应用商店以来发布的所有实时更新。

监控和应对问题

标题:监控和应对问题

为了快速发现问题并尽量减少不稳定更新的影响,需要制定监控发布和应对问题的计划。

一些策略包括:

  • 监控发布后立即收集崩溃报告和用户反馈
  • 使用分段发布或分阶段渠道系统在较小的用户组中测试更新,然后进行大规模发布
  • 制定明确的决策流程,包括何时回滚、解除绑定或强制使用内置包,以及谁有权利进行此操作
  • 在适当的情况下向用户说明问题和解决方案

通过结合谨慎的监控和快速管理不稳定更新的能力,可以提供持续改进的应用体验,同时尽量减少对用户的干扰