回滚

虽然 Capgo 的实时更新允许您快速向用户提供改进和修复，但在某些情况下，您可能需要回滚到应用程序的前一个版本。也许新更新引入了一个意想不到的关键问题，或者您想在修复期间恢复特定更改。

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

自动回滚保护

Capgo 包括一个内置的安全机制来保护您的用户免受破坏的更新。发生 JavaScript 错误之前，如果方法未被调用，插件将自动回滚到上一个工作版本。 notifyAppReady() 自动回滚工作原理

__CAPGO_KEEP_0__

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

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

如果 notifyAppReady() 没有被调用，因为JavaScript崩溃或关键错误，Capgo 将:

1. 检测到更新未正确初始化
2. 自动切换回上一个工作包
3. 标记问题更新为失败，以防止它再次应用

提示

确保在应用程序初始化时调用 notifyAppReady() 在应用程序的初始化中 code 在核心组件加载成功后。 这样可以确保自动回滚保护工作正常。

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

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

此自动保护可以确保即使您意外推送了一个错误的更新，用户也不会被困在一个不可用的应用程序中。

配置超时

您可以配置 Capgo 等待多长时间 notifyAppReady() 被调用 appReadyTimeout in your Capacitor configuration:

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

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

回滚到之前的捆绑包

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.

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.

使用历史标签回滚的步骤:

1. 登录到 Capgo Dashboard.

2. 导航到“频道”部分。

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

4. 在频道视图中，转到第4个标签（历史）

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

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

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

备选方法：使用皇冠图标

作为第二种方式，您也可以直接从频道视图的第一个标签页回滚，点击频道构建历史中任何构建旁边的皇冠图标：

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

注意

仅影响所选频道的回滚。若您有多个频道（例如生产环境、测试环境等），则需要对每个受影响频道重复回滚过程。

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

加速关键回滚通知

重定向频道通常在下一次设备检查更新时生效。Capgo 通知可以在应用程序处于后台时发送一个静默更新检查通知。启用更新器集成后，应用程序可以根据其配置的更新模式检查、下载并安装回滚。

这不是一个强制性命令，仅提供加速路径。交付依赖于操作系统的后台调度、网络可用性和设备状态。它无法更新离线或强制退出的应用程序，因此无法保证到达每个设备的固定时间。

要设置此路径，请遵循 通知：启用静默更新检查.

解除频道绑定

若要暂时停止某个频道的更新以便调查问题，您可以解除该频道与其当前构建的绑定。

要解除频道绑定：

1. 进入Capgo控制台的频道。

2. 点击当前构建旁边的“解绑”按钮。

3. 确认要解绑频道。

一旦频道解绑，任何新更新都不会被分发。配置为该频道的设备将保持在当前构建状态，直到频道再次链接到一个构建。

如果您已经确定了更新中的问题，但还不知道要回滚到哪个构建，解绑频道是有用的。解绑频道可以让您有时间调查而不推送进一步的更新。

强制内置捆绑包

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

要在频道上强制内置捆绑包，请执行以下步骤：

1. 进入Capgo控制台的频道。

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

3. 确认要强制内置捆绑包。

当您强制使用内置包，所有已配置到该频道的设备将在下一次更新检查时恢复到原始打包的Web构建。这不论他们当前的构建版本如何都发生。

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

注意

在强制使用内置包时，请谨慎，因为它将影响频道上的所有设备。确保您已考虑到影响并有一个计划来向前移动之前采取此行动。

监控和应对问题

为了快速捕捉问题并最小化有问题更新的影响，监控您的发布并应对问题的计划非常重要。

一些策略包括：

对于仍然限于小组的发布，使用 渐进式发布 暂停暴露或清除目标之前更改整个频道的稳定包。

• 立即在发布更新后监控崩溃报告和用户反馈
• 使用分阶段发布或分阶段渠道系统在较小的用户组中测试更新，避免大规模发布
• 明确决定何时回滚、解除关联或强制使用内置包，以及谁有权利进行此操作
• 向用户说明问题和解决方案（如果适用）

通过结合监控和快速管理问题更新的能力，您可以提供持续改进的应用体验，同时最小化对用户的干扰

继续从回滚

如果您正在使用 回滚 来规划回滚和版本控制，连接它到 版本目标 上下文：Capgo解决方案营销页面。角色：部分或页面标题。见于：页面解决方案/版本目标.astro。消息键`解决方案版本目标标题` (Solutions Version Targeting Title)。| 上下文：Capgo解决方案营销页面。角色：短UI标签或导航项。见于：页面解决方案/版本目标.astro。消息键`解决方案版本目标` (Solutions Version Targeting)。 更新行为 为更新行为的实现细节 包 为包的实现细节 Capgo 实时更新 为Capgo 实时更新的产品工作流程 Capacitor 实时更新的回滚策略 为Capacitor 实时更新的实际背景