回滚

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

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

自动回滚保护

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

关于“自动回滚的工作原理”的部分

When a new update is downloaded and applied, Capgo expects your app to call notifyAppReady() JavaScript 包裹在没有关键错误的情况下加载

• __CAPGO_KEEP_0__ expects your app to call __CAPGO_KEEP_0__ within a configurable timeframe to confirm that the update loaded successfully. This method signals that:
• 您的应用程序的核心功能正在工作
• 更新是安全的

如果 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()

This automatic protection helps ensure that even if you accidentally push a broken update, your users won’t be stuck with a non-functional app.

配置超时

You can configure how long Capgo waits for notifyAppReady() to be called by setting the appReadyTimeout in your Capacitor configuration:

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

The appReadyTimeout value is specified in milliseconds. The default timeout is typically 10 seconds, but you can adjust this based on your app’s initialization requirements. If your app takes longer to load due to complex initialization processes, you may want to increase this value.

回滚到上一个捆绑包

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

通过回滚界面来回滚，回滚界面位于Capgo控制台的第4个标签（历史记录）中。当你在Capgo控制台中查看一个频道时，历史记录标签提供了所有可用的频道版本的全面视图，方便你选择并回滚到任何之前的版本。

使用历史记录标签回滚的步骤：

1. 登录到 Capgo控制台.

2. 进入频道部分

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

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

5. 在频道历史记录中找到你要回滚的版本

6. 选择该版本，设置其为频道的活动版本

7. 确认你要回滚到该版本

备选方法：使用皇冠图标

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

1. 在频道视图的第一个选项卡中，找到您要回滚到的构建。
2. 点击该构建旁边的冠军图标，来使该构建成为频道的活动构建。
3. 确认您要回滚到此构建。

注意

回滚到之前的构建只会影响所选频道。如果您有多个频道（例如生产、测试等），则需要重复回滚过程以影响每个频道。

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

解除频道关联

如果您想暂时停止某个频道的更新以便调查问题，您可以将该频道从其当前的构建中解除关联。

要解除频道关联：

1. 在Capgo控制台中找到该频道并点击进入。

2. 单击当前构建旁边的“解除关联”按钮。

3. 确认您要解除频道关联。

一旦频道解除了关联，它就不会再分发任何新更新。已配置为使用该频道的设备将继续使用其当前的构建，直到频道再次关联到一个构建为止。

这对于您已经确定了更新问题，但尚未确定要回滚到哪个构建的情况非常有用。解除频道关联可以让您有时间调查而不推送进一步的更新。

强制内置包

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

要在频道中强制内置包：

1. 在Capgo控制台中找到该频道并点击进入。

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

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

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

这比回滚到特定之前的构建更为激进的回滚选项，因为它丢弃了自应用最后发布到应用商店以来发布的所有实时更新。

注意

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

监控和应对问题

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

一些策略包括：

• 立即监控崩溃报告和用户反馈以监控问题。
• 使用分阶段发布或分阶段渠道系统测试更新在较小的群体中发布
• 明确决定何时回滚、解除关联或强制内置捆绑包，以及谁有权这样做
• 向用户说明问题和解决方案，如果适当

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

__CAPGO_KEEP_0__

如果您正在使用 回滚 来规划回滚和版本控制，连接它与 版本目标 获取版本目标的实施细节 更新行为 在 Update Behavior 中的实现细节 打包 在打包中实现细节 Capgo 实时更新 在 Capgo 实时更新中的产品工作流程 Capacitor 实时更新的回滚策略 Capacitor 实时更新中的实际背景