Capgo

暂停发布会停止发布到更多设备。回滚会将受影响的设备推向一个已知的良好版本。 Capgo __CAPGO_KEEP_0__

支持两者，所以您可以先包含问题并决定下一步。

使用这些步骤来选择正确的动作，检查其效果，并减少重复事件的机会。

我们阅读了 6 个关于阶段发布和回滚的公开指南，发布于 Google Play、Amazon Appstore、Microsoft 的 CodePush、Bitrise、Nearform 和 Digia。其中 4 个将暂停和回滚作为不同的动作分开，而 2 个则跳过回滚或将暂停作为唯一的杠杆。没有任何 6 个指南解释如何通过分析或设备检查来验证恢复，也没有描述预防重复事件的工作流程。正确选择暂停和回滚的选择，然后确认它有效，填补了公共发布指南中留下的空白。

• 步骤 1：在 Capgo 中设置发布控制
• 步骤 1：在 __CAPGO_KEEP_0__ 中设置发布控制
• 步骤 2：选择是否暂停或回滚
• 步骤 3：暂停进一步暴露以进行调查
• 步骤 4：在用户需要稳定版本时回滚
• 第 6 步：通过更安全的发布流程预防重复事件
• 常见问题
• 结论

第 1 步：在 Capgo 中设置发布控制

在事件发生之前，确保您的团队知道哪个渠道正在传递发布，并且哪个捆绑包是稳定的。一个渠道是指向更新的命名通道，指向设备的更新。一个捆绑包是通过该通道传递的可更新的 Web code。

在 Capgo 中，渐进式发布可以在稳定捆绑包的基础上发送一个单独的发布目标给一个选定的组。这样就给您一个控制点，直到新捆绑包到达更广泛的用户群之前。查看 渐进式发布控制 在生产环境中启用之前，

写下发布负责人和应该停止扩展的信号。例如，决定您的团队在更新失败率上升、关键屏幕停止工作或支持报告用户无法完成任务时会做什么。根据您的应用的正常行为来设置限制，而不是仅仅因为它听起来严格就选择一个阈值。

OTA 更新会在空中改变应用的可更新 code。它不会替换从应用商店安装的原生应用二进制文件。这个术语“空中更新”描述了这种传递方式。请记住这个界限：如果修复需要一个新的原生插件或应用的原生设置的更改，捆绑包回滚就无法提供它。

发布前，请确认稳定包是否为您期望的包。检查频道名称、目标包和发布状态。频道名称中的一个小错误或目标包过时可能会在关键时刻导致响应者走向错误的控制。

到目前为止，您应该已经有了一个命名的发布负责人、一个已知的良好包和一个书面停止条件。这种准备使下一个决定变成一个运营选择，而不是在仪表板上疯狂地寻找。

关键 takeaway: 暂停限制新暴露。回滚会改变用户接收的版本。

步骤 2：选择是否暂停或回滚

For the Capgo pause rollout vs rollback decision, ask one question first: are you trying to stop more devices from getting the target, or move devices off a target that’s already causing harm? A pause limits new exposure. A rollback clears the target and returns devices to the stable fallback on their next update check.

对于 __CAPGO_KEEP_0__ 暂停发布 vs 回滚决策，请先问一个问题：您是否试图阻止更多设备接收目标包，还是将设备从已经造成损害的目标上移开？暂停会限制新暴露。回滚会清除目标并将设备返回到下一次更新检查时的稳定fallback版本。

选择回滚时，目标明显不安全于用户，或团队有足够的证据证明已知良好的包更安全。单独暂停不会从已经加入回滚分组的设备中移除坏的目标。如果这些用户需要返回到稳定状态，回滚是改变他们更新路径的动作。

The Capgo频道CLI参考 lists separate pause and rollback controls. Treat them as different actions, not two names for the same emergency stop.

回滚不会修复后端故障，也不能添加缺失的原生能力。首先确定哪一层失败。如果web包是问题所在，根据需要缓解用户人数选择暂停或回滚

步骤3：暂停进一步暴露以进行调查

上下文：关于Capgo页面。角色：UI标签。见于：关于.astro页面。消息键`about_how_step_label`（关于如何步骤标签）

Open the production channel and verify that you’re acting on the affected rollout. Pause it with the dashboard, CLI, or API control your team uses. Then read the channel state back. Don’t rely only on a command completing successfully; confirm the rollout now shows as paused.

在Capgo的渐进式发布模型中，已经加入分组的设备在暂停后仍然可以保持在发布目标。新符合条件的设备在下一次检查时会接收稳定fallback。这种区别很重要：暂停停止新加入，但它本身并不会将现有分组回滚到稳定。

接下来，捕获发布细节之前再进行另一个改变。记录目标包、通道、暂停时间和第一个已知报告。保留设备或会话详细信息，团队允许收集。清晰的时间线有助于您将发布分组与仍在稳定包中的设备进行比较。

通过可重复的路径检查问题。如果用户报告登录失败，测试受影响设备上的该exact旅程。如果应用在启动时崩溃，检查崩溃是否与新包和本机应用程序版本相符。避免将每个支持报告视为更新导致问题的证据。

设置调查的负责人和决策时间。暂停的发布如果没有人负责下一步，可能会在无限期停滞。负责人应该在证据清除发布后恢复发布，或者在目标仍然不安全时选择回滚。

Pro Tip： 告知支持团队和发布团队发布已暂停。否则，一组可能会继续升级报告，而另一组可能会假设发布已经被逆转。

到目前为止，新设备应该不再进入发布阶段。检查频道状态和之前不在发布阶段的设备的行为，然后才能进行回滚或恢复。

步骤 4：当用户需要稳定版本时，回滚

当用户已经在目标版本上，需要回滚到已知的良好包时，进行回滚。这比暂停更强的响应。它会改变频道提供的内容，所以在确认操作之前，请务必验证所选的稳定版本。

在 Capgo 中，打开受影响的频道并查看其构建历史。选择要恢复的版本，然后确认它是此应用程序和频道的正确稳定包。 Capgo 的 回滚文档 描述了仪表板路径和设备在下一次检查更新时接收所选构建的细节。

回滚后，不要假设所有设备都同时改变。设备需要检查更新，而离线用户可能直到后来才会做到这一点。保持事件开放，直到您检查频道的活动版本并在受影响的分组中测试恢复路径的设备。

仅在使用内置包时才使用它，除非这是恢复目标。它会将设备指向内置在原生应用中的Web构建，这可能与最后一次OTA包不同。检查兼容性和用户影响之前，请不要将其作为恢复步骤。

除非你的保留过程有其他要求，否则请保留引起事件的包供分析。发布ID和提交有助于工程师将变化与稳定版本进行比较。清理前请保存相关日志，尤其是如果你需要了解为什么问题逃避了测试。

回滚并不是每次失败的正确解决方案。如果根源是服务端依赖项，请修复该服务。如果变化依赖于本地code但安装的二进制文件中缺失，请准备本地构建并按照应用商店发布路径进行该变化。

步骤5：通过分析和设备检查验证恢复

context

Capgo’s live update analytics can help you inspect adoption metrics, error rates, and device-level logs. Use those signals to answer specific questions: are new devices still receiving the target, are affected devices checking for the stable bundle, and did the reported failure stop after recovery?

测试失败的用户路径。成功下载并不意味着应用程序正常工作。打开相关屏幕，重复导致报告的操作，并验证应用程序达到预期状态。如果事件涉及关键流程，请让其他人确认结果（除了修改者）。

比较类似的事物。广泛的错误计数可能会因与发布无关的原因而上升，例如服务问题或流量变化。过滤按捆绑、频道、应用程序版本和设备（当这些字段可用时）。寻找与发布相关的差异，而不是默认地指责最新的更新。

还要检查尚未更新的用户。他们的存在可能会使整体指标看起来健康，而受影响的群体仍然看到错误。跟踪目标版本的设备比例与稳定版本的设备比例，并将支持报告与用户实际运行的版本绑定。

记录恢复结果和剩余的不确定性。如果错误下降，但仍有少数用户报告相同的问题，不要关闭事件，直到您了解他们是否脱离线、使用旧的本机 shell 还是仍在使用受影响的捆绑。

恢复确认时，频道指向预期版本，失败的用户路径在可以复制问题的设备上工作。指标有助于您了解问题的形状；设备检查确认一个人经历的内容。

第 6 步：通过更安全的发布流程预防重复事件（关于 Capgo 页面）

发布前，应将暂停和回滚作为发布计划的一部分。发布负责人应了解谁可以停止暴露并谁可以批准恢复到稳定状态。这样可以消除一个常见的延迟：等待会议期间更多设备进入发布阶段。

在发布目标测试期间，应保留稳定的回退分配。使用小的、定义的队伍首先，然后在同意的健康信号保持在您的限制内时才扩大。Capgo 支持基于通道的发布控制，因此团队可以将测试与广泛的生产交付分开。

将发布检查放入 CI/CD，自动化的过程可以运行测试并部署更改。管道可以在测试通过后将包发布到指定的通道。它也应该在通道错误或发布尚未准备好推广时安全失败。

持续交付工作流程使软件通过自动化过程保持发布就绪。对于 OTA 工作流程，应在发布自动化时保持人类批准点清晰。自动化应该使选择的动作可重复，而不是为未审查的更改做出决定。

使用 Capgo，可以使用一条命令将包发布到指定的通道。将命令放入与检查相同的发布过程中，并在发布记录中使目标通道可见。这样可以帮助 on-call 工程师看到具体什么被发布而不必猜测哪个通道接收了它。

在启用自动保护机制之前，需要定义触发信号和相应动作。暂停可以停止新设备的暴露，而当前设备仍然保持在目标状态。回滚可以将设备指向稳定状态。这些结果不同，因此不要将其配置为彼此的替代品。

使用测试频道来模拟整个响应过程。发布一个无害的更改，验证暂停控制，然后测试回滚到之前的包。确认在每个动作之后的应用行为。写好的运行书应该包括频道、命令或控制台路径、预期状态和确认成功的人员。

发布说明应该标识包及其目的。保持部署记录和源代码之间的链接，以便工程师可以在出现错误时缩小搜索范围。如果团队跨时区处理事件，请包括最后一次操作和下一个决策者。

如果事件指向更广泛的前端实现瓶颈，可能需要一个像 阿米尔阿雷佐 可能与网站开发工作相关。与Capgo的发布控制相比，它们专门处理兼容应用程序更新的交付和恢复。

__CAPGO_KEEP_0__

FAQ

是否暂停Capgo更新后设备的回滚

暂停不会阻止已入群的设备继续使用目标版本，但会阻止新设备进入。要将用户推回稳定版本，请使用回滚或其他有意的渠道操作。检查渠道状态后，在接收目标版本的设备上确认结果。

什么时候应该暂停而不是回滚?

暂停时，问题仍在调查中，需要停止更广泛的暴露。回滚时，目标版本已知会损害用户或受影响设备需要稳定的版本。Capgo 暂停回滚的选择取决于是否立即需要控制或恢复现有群组。

回滚会立即更新所有设备吗?

不。回滚会改变渠道指向的版本，但设备在下一次检查更新时才会接收到。离线设备可能会继续使用当前版本直到重新连接。请先验证渠道目标，然后检查受影响设备和更新状态，才能宣布事件解决。

OTA 回滚能否修复本机应用程序问题?

不。OTA 回滚可以恢复更早的可更新的 Web 版本，但无法添加或删除本机 code 内部已安装的应用程序二进制文件。如果问题来自本机插件或应用程序壳的变化，应评估是否需要新本机构建。首先确定哪一层引起了故障。

暂停或回滚后应该检查什么?

确认渠道的状态和活跃的捆绑包，然后检查发布的更新采用率和错误。测试在受影响组中的设备上失败的用户旅程。还检查尚未更新的设备，因为整体指标可能会掩盖受限于一个版本或一群的问题。

结论

暂停时需要停止新暴露的同时进行调查。回滚时，目标用户需要稳定的版本。提前设置两种控制，然后在测试渠道上进行演练，准备下一个生产发布。