Capgo 暂停发布与回滚：何时使用哪种

暂停会阻止 rollout 覆盖更多设备；回滚则把受影响的设备切回已知良好的版本。 Capgo 支持这两种操作，因此你可以先控制住问题，再决定下一步怎么做。

按以下步骤选择正确的操作、检查效果，并降低事件再次发生的概率。

我们研读了 Google Play、Amazon Appstore、Microsoft 的 CodePush、Bitrise、Nearform 和 Digia 发布的 6 份关于分阶段 rollout 和回滚的公开指南。6 份中有 4 份将暂停和回滚视为两种不同的操作，另外 2 份则未涉及回滚，或把暂停当作唯一手段。这 6 份指南都没有说明如何通过分析数据或设备检查来验证恢复，也没有一份给出防止事件再次发生的工作流。正确选择暂停还是回滚，并确认其生效，可以填补公开的发布指南中普遍存在的空白。

目录

• 步骤 1：在 Capgo 中设置发布控制
• 第 2 步：选择暂停还是回滚
• 步骤 3：排查期间暂停进一步曝光
• 步骤 4：当用户需要稳定版本时回滚
• 第 5 步：用数据分析和设备检查验证恢复情况
• 第 6 步：通过更安全的发布工作流防止事故再次发生
• 常见问题
• 总结

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

在事故发生前，确保团队清楚哪个 channel 正在分发该 release，以及哪个 bundle 是稳定的。Channel 是一条命名通道，用于将应用设备引导至更新。Bundle 则是通过该通道发送的可更新 Web code。

在 Capgo 中，渐进式 rollout 可以在保持稳定 bundle 不变的同时，向选定组发送独立的 rollout 目标。这在新 bundle 触达更广泛用户群之前，为你提供了一个控制点。请查看 渐进式 rollout 控制 在生产环境中启用之前。

明确发布负责人，以及应当停止扩大的信号。例如，决定当更新失败增多、关键界面无法使用，或支持团队报告用户无法完成任务时，团队该如何应对。应根据应用的正常行为设定限制，而不是只因为听起来严格就随便选一个阈值。

OTA 更新会以无线方式更改应用中可更新的 code。它不会替换从应用商店安装的原生应用二进制文件。“over-the-air 更新”一词描述的就是这种交付方式。请记住这个界限：如果修复需要新的原生插件，或要更改应用的原生配置，bundle 回滚也补不上。

发布前，确认稳定 bundle 正是你预期的那个。检查 channel 名称、目标 bundle 和 rollout 状态。分秒必争时，channel 名称拼错或目标过旧，会让响应人员找错控制项。

到这一步，你应该已有指定的发布负责人、已知可用的 bundle 和书面的停止条件。做好准备后，接下来的决策就是一项运营选择，而不是在 dashboard 里手忙脚乱地翻找。

核心要点： 暂停可限制新增暴露；回滚则会改变引导用户接收的版本。

第 2 步：选择暂停还是回滚

在决定 Capgo 的 pause rollout 还是 rollback 时，先问一个问题：你是想阻止更多设备获取目标版本，还是让设备脱离已经造成问题的目标版本？Pause 会限制新的暴露范围；rollback 会清除目标版本，并在设备下次检查更新时将其恢复到稳定的 fallback 版本。

当证据不完整或问题范围似乎有限时，请选择 pause。你可能只有少量报告，但不知道这个 bug 是只影响某种设备类型、特定用户流程，还是所有已更新设备。Pause 能让团队在不把新设备加入 rollout 组的情况下，有时间分析这些信号。

当目标版本明显对用户不安全，或者团队已有足够证据证明已知良好的 bundle 更安全时，请选择 rollback。仅靠 pause 无法从已进入 rollout 批次的设备上移除有问题的目标版本。如果这些用户需要回到稳定版，rollback 才是改变其更新路径的操作。

本指南中介绍的 Capgo channel CLI 参考 列出了独立的 pause 和 rollback 控制项。请把它们视为不同的操作，而不是同一个紧急停止的两种叫法。

回滚无法修复后端故障，也无法补上缺失的 native 能力。先确定是哪一层出了问题。如果问题出在 web bundle，就根据有多少用户需要缓解影响，在暂停和回滚之间做选择。

步骤 3：排查期间暂停进一步曝光

当需要阻止新设备进入 rollout 组，但还没准备好为已在组内的设备回滚 target 时，请使用 Pause。这是一个控制步骤，既能争取时间核实情况，又能避免问题扩散到更多用户。

打开 production channel，确认你操作的是受影响的 rollout。用 dashboard、CLI 或团队使用的 API 控件将其暂停。然后回读 channel 状态。不要只看命令是否执行成功，要确认 rollout 现在显示为 paused。

在 Capgo 的渐进式 rollout 模型中，已在 cohort 中的设备在暂停后仍可保留在 rollout target 上。符合条件的新设备在下次检查时会收到 stable fallback。这个区别很重要：暂停会阻止新设备进入，但本身不会把现有 cohort 移回 stable。

接下来，在做其他更改前先记录发布详情。记录 target bundle、channel、暂停时间以及首个已知报告。保存团队获准收集的设备或 session 详情。清晰的时间线有助于你将 rollout cohort 与仍在 stable bundle 上的设备进行对比。

通过可重复的路径排查问题。如果用户报告登录失败，请在受影响的设备上测试完全相同的流程。如果应用在启动时崩溃，请检查崩溃是否与新的 bundle 和 native app 版本吻合。不要把每条客服反馈都当成更新导致问题的证据。

为调查指定负责人和决策时间。如果没人负责下一步，暂停的 rollout 可能一直悬而未决。负责人应在证据表明发布无问题后恢复，或在目标仍不安全时选择回滚。

专家提示： 告知支持团队和发布团队 rollout 已暂停。否则，一方可能继续上报问题，而另一方以为 rollout 已经回滚。

此时，新设备不应再进入 rollout 批次。在回滚或恢复之前，请检查 channel 状态，以及一个原本不在该批次中的设备的行为。

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

当已使用目标版本的用户需要回退到已知良好的 bundle 时，执行回滚。这比暂停是更强力的应对措施。它会改变 channel 分发的版本，因此在确认操作前，请验证所选的稳定 build。

在 Capgo 中，打开受影响的 channel 并查看其 build 历史。选择要恢复的版本，然后确认它是该应用和 channel 对应的正确稳定 bundle。Capgo 的 回滚文档 描述了 dashboard 路径，并指出设备将在下次检查更新时接收所选的 build。

回滚后，不要以为所有设备会同时切换。设备需要检查更新，离线用户可能过一阵才会检查。在确认 channel 的当前活跃版本，并在受影响用户群中的设备上测试恢复路径之前，不要关闭事件。

仅在确定要恢复到内置 bundle 时才使用它。这会把设备指回原生 App 内置的 Web build，该版本可能与上一个 OTA bundle 不同。在将其作为恢复步骤前，请先确认兼容性和对用户的影响。

除非你的保留流程另有规定，否则请保留导致故障的 bundle 以供分析。Release ID 和 commit 能帮助工程师将这次变更与稳定版本对比。清理前请保留相关 logs，尤其是在需要弄清该问题为何没被测试发现时。

Rollback 并不适用于所有故障。如果根本原因是服务端依赖，请修复该服务。如果变更依赖已安装的二进制文件中缺失的 code，请准备 Native Build，并针对该变更走应用商店的发布流程。

第 5 步：用数据分析和设备检查验证恢复情况

在执行 Pause 或 Rollback 后，要去看设备实际在做什么，而不是把控制项的变更当作恢复成功的证明。先检查 active channel 的状态，再对比受影响版本与稳定版本在更新采纳率、错误和设备报告上的差异。

Capgo 的 live update 分析功能可帮助你查看采用指标、错误率和设备级 logs。用这些信号回答具体问题：新设备是否仍在接收目标版本？受影响的设备是否在检查 stable bundle？报告的故障在恢复后是否停止？

测试失败的用户路径。下载成功并不代表 App 运行正常。打开相关界面，重复导致该报告的操作，并验证 App 是否达到预期状态。如果故障涉及关键流程，请让变更者以外的人确认结果。

做同类对比。总体错误数上升可能与发布无关，例如服务问题或流量变化。在字段可用时，按 bundle、channel、App 版本和设备筛选。寻找与发布相关的差异，而不是默认归咎于最新更新。

同时检查尚未更新的用户。他们的存在可能让整体指标看起来很健康，而受影响的用户群仍遇到该 bug。对比目标版本与 stable 版本的设备占比，并让支持报告对应到用户实际运行的版本。

记录恢复结果和剩余的不确定性。如果错误减少但仍有少数用户报告相同问题，在弄清他们是否离线、是否使用旧版原生壳，还是仍在使用受影响的 bundle 之前，不要关闭该故障。

当 Channel 指向目标版本，且之前失败的用户路径在能复现该问题的设备上恢复正常时，即可确认恢复成功。指标能帮你了解问题的整体情况；设备检查则确认用户的实际体验。

第 6 步：通过更安全的发布工作流防止事故再次发生

在发布前，把暂停和回滚纳入发布计划。发布负责人应清楚谁能停止放量、谁能批准回退到稳定版。这能消除一个常见延迟：等开会时，更多设备已经进入 rollout。

在测试 rollout 目标时，始终指定一个稳定的回退版本。先使用一小批明确定义的用户群，只有当约定的健康信号保持在你的阈值内时才扩大范围。Capgo 支持基于 Channel 的发布控制，让团队能把测试与大规模生产交付分开。

将发布检查放进 CI/CD（运行测试并部署变更的自动化流程）。Pipeline 可以在测试通过后把 bundle 发布到目标 Channel。如果 Channel 不对或发布尚未准备好晋级，Pipeline 也应安全失败。

持续交付工作流通过自动化流程让软件随时处于可发布状态。对于 OTA 工作流，即使发布过程是自动化的，也要保持明确的人工审批环节。自动化的目的是让选定的操作可重复执行，而不是代替人工对未经审核的变更做出决策。

使用 Capgo，一条命令即可将 bundle 发布到指定 channel。请将此命令纳入与检查步骤相同的发布流程，并在部署记录中明确显示目标 channel。这样，值班工程师就能准确查看发布内容，无需猜测具体是哪个 lane 接收了更新。

在启用自动保护机制之前，先定义触发信号及其执行的操作。暂停可以阻止新的曝光，同时让当前群组设备保持在目标版本。回滚则可以将设备引导至稳定版本。由于结果不同，请勿将一种配置为另一种。

使用测试频道演练完整的响应流程。发布一个无害的更改，验证暂停控制，然后测试回滚到之前的 bundle。在每次操作后确认设备上的应用行为。书面运行手册应包含频道、命令或 dashboard 路径、预期状态以及确认成功的人员。

发布说明应识别 bundle 及其目的。保持部署记录与源更改之间的链接，以便工程师在出现错误时缩小搜索范围。如果您的团队跨时区交接事故，请包含最后采取的操作和下一个决策负责人。

如果事故指向更广泛的前端实现瓶颈，像 Amir Arezoo 这样的 Web 开发者可能适合网站开发工作。这与 Capgo 的发布控制是分开的，后者处理兼容应用更新的交付和恢复。

现在，你的发布流程应包含稳定的回退方案、负责人、停止规则和经过测试的恢复操作。工作流要足够简短，让值班工程师在压力下也能用。

常见问题

暂停 Capgo rollout 会让已更新的设备回退吗？

不会。暂停会阻止新的符合条件的设备进入 rollout，但已在 cohort 中的设备仍可停留在目标 bundle 上。要让这些用户回到稳定版本，请使用 rollback 或其他明确的 channel 操作。无论执行哪种更改，之后都请检查 channel 状态，并在已接收目标版本的设备上确认结果。

什么时候该暂停而不是 rollback？

问题仍在调查中、需要阻止影响扩大时，请暂停。已知目标版本会伤害用户，或受影响设备需要稳定 bundle 时，请 rollback。Capgo pause rollout vs rollback 怎么选，取决于当前首要需求是控制影响还是恢复现有 cohort。

rollback 会立即更新所有设备吗？

不会。rollback 会更改 channel 指向的 bundle，但设备要等到下次检查更新时才会收到。离线设备可能会一直停留在当前 bundle，直到重新连接。在宣布故障解决前，请先核实 channel 目标，并检查受影响设备及其更新状态。

OTA rollback 能修复原生 App 的问题吗？

不。OTA 回滚可以恢复之前的可更新 Web bundle，但无法在已安装的应用二进制文件中添加或移除原生 code。如果问题源于原生插件或应用外壳（app-shell）的变更，请评估是否需要新的原生构建。首先确定是哪一层导致了故障。

暂停或回滚后，我应该检查什么？

确认渠道状态和当前活跃的 bundle，然后按版本检查更新采用率和错误。在受影响组别的设备上复现失败的用户旅程。同时检查尚未更新的设备，因为整体指标可能会掩盖仅限于特定版本或用户群的问题。

总结

在调查期间需要停止新用户暴露时，使用暂停。当目标用户需要稳定版本时，使用回滚。提前配置好这两种控制机制，并在下一次生产发布前在测试渠道上进行演练。