Capgo 暂停发布 vs 回滚：何时用哪个

暂停 (Pause) 会阻止 rollout 推送到更多设备；回滚 (Rollback) 则会将受影响的设备切换回已知稳定的版本。 Capgo 两者均支持，因此你可以先控制问题范围，再决定下一步操作。

通过这些步骤来选择正确的操作、检查执行效果，并降低此类事件再次发生的概率。

我们研读了 Google Play、Amazon Appstore、Microsoft CodePush、Bitrise、Nearform 和 Digia 发布关于分阶段 rollout 和 rollback 的 6 份公开指南。其中 4 份将暂停与回滚视为两种截然不同的操作，而另外 2 份则忽略了回滚，或仅将暂停作为唯一的手段。这 6 份指南中，没有一份解释了如何通过分析数据或设备检查来验证恢复情况，也没有说明如何防止此类事件再次发生。选对暂停与回滚的方案并确认其生效，可以填补目前公开发布指南中的这一空白。

目录

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

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

在事故发生前，请确保您的团队清楚哪个 channel 正在发布该版本，以及哪个 bundle 是稳定的。Channel 是一个命名的通道，负责将 app 设备引导至特定的 update。Bundle 则是通过该通道发送的可更新 web code。

在 Capgo 中，渐进式发布（progressive rollout）可以在保留稳定 bundle 的同时，向选定群体发送独立的发布目标。这让您在新的 bundle 推送到更广泛的用户群之前，拥有一个控制点。查看 渐进式发布控制 在生产环境中启用之前。

明确发布负责人以及应当停止扩大的信号。例如，决定当更新失败率上升、关键界面停止工作或支持团队报告用户无法完成任务时，团队应如何应对。应根据应用的正常行为设定限制，而不是仅仅为了显得严格而随意挑选阈值。

OTA 更新通过网络更改应用中可更新的 code。它不会替换从应用商店安装的原生应用二进制文件。“Over-the-air”一词描述了这种交付方式。请务必记住这一界限：如果修复方案需要新的原生插件或更改应用的原生配置，bundle rollback 是无法实现的。

发布前，请确认当前的稳定 bundle 正是你预期的版本。检查 channel 名称、目标 bundle 以及 rollout 状态。在分秒必争的关键时刻，channel 名称的拼写错误或过时的目标可能会导致响应人员采取错误的控制措施。

到这一步，你应该已经有了明确的发布负责人、经过验证的稳定 bundle 以及书面的停止条件。这些准备工作能让接下来的决策变成一次标准的操作选择，而不是在 dashboard 中手忙脚乱地寻找。

核心要点： Pause 会限制新用户的接触范围。Rollback 则会改变用户接收到的版本。

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

在决定使用 Capgo pause rollout 还是 rollback 时，首先要问一个问题：你是想阻止更多设备获取目标版本，还是想让已经受到影响的设备撤回？Pause 会限制新的暴露；而 Rollback 则会清除目标版本，并在下次检查更新时让设备恢复到稳定的回退版本。

当证据不足或问题看起来范围有限时，请选择 Pause。你可能收到了一些报告，但不确定该 bug 是仅影响某种设备类型、特定的用户流程，还是所有已更新的设备。Pause 可以让团队在不增加新设备进入 rollout 组的情况下，有空间去排查信号。

当目标版本对用户明显不安全，或者团队已有足够证据证明已知良好的 bundle 更安全时，请选择 Rollback。仅靠 Pause 并不能从已在 rollout 队列中的设备上移除错误的目标版本。如果这些用户需要回到稳定版，Rollback 才是改变其更新路径的操作。

该 Capgo 频道 CLI 引用 列出了独立的 pause 和 rollback 控制项。请将它们视为不同的操作，而不是同一种紧急停止手段的两种称呼。

回滚无法修复后端故障，也无法补齐缺失的 native 能力。首先确定是哪一层出了问题。如果 web bundle 有误，请根据受影响用户规模，在暂停发布或回滚之间做出选择。

步骤 3：在排查期间暂停进一步暴露

当您需要阻止新设备进入 rollout 组，但尚未准备好回滚已在其中的设备时，请使用 Pause。这是一种遏制手段，可以在防止问题扩散至更多用户的同时，为您争取核实事实的时间。

打开 production channel 并确认您正在操作的是受影响的 rollout。通过 dashboard、CLI 或您团队使用的 API 来执行 Pause。随后请重新读取 channel 状态。不要仅依赖命令执行成功，务必确认 rollout 当前已显示为 paused 状态。

在 Capgo 的渐进式 rollout 模型中，已在 cohort 中的设备在 pause 后仍会保留在当前的 rollout target 上。符合条件的新设备在下次检查时会收到稳定的 fallback 版本。这种区别至关重要：pause 会停止新设备进入，但它本身不会将现有的 cohort 移回 stable 版本。

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

通过可复现的路径排查问题。如果用户报告登录失败，请在受影响的设备上测试该完整流程。如果应用在启动时崩溃，请检查崩溃是否与新的 bundle 及 native app 版本一致。避免将每一条支持请求都直接视为更新导致问题的证据。

为调查设定负责人和决策时间。如果没有人负责后续行动，暂停 rollout 可能会陷入停滞状态。负责人应在证据证明发布安全后恢复 rollout，或者在目标版本仍不安全时选择 rollback。

专家提示： 告知支持团队和发布团队 rollout 已暂停。否则，可能会出现一组人员在不断上报问题，而另一组人员却认为 rollout 已经回滚的情况。

此时，新设备不应再进入该 rollout cohort。在执行 rollback 或 resume 之前，请检查 channel 状态以及之前不在 cohort 中的设备行为。

第 4 步：当用户需要稳定版本时进行 Roll back

当已处于目标版本的用户需要退回到已知良好的 bundle 时，请执行 Roll back。这比暂停（pausing）是更强力的响应措施。因为它会改变 channel 提供的内容，因此在确认操作前，请务必验证所选的稳定 build。

在 Capgo 中，打开受影响的 channel 并查看其 build history。选择您想要恢复的版本，然后确认它是该 app 和 channel 正确的稳定 bundle。Capgo 的 rollback 文档 描述了 dashboard 中的操作路径，并指出设备将在下次检查 update 时接收所选的 build。

执行 rollback 后，不要假设所有设备都会立即发生变化。设备需要主动检查 update，而离线用户可能要到稍后才会执行此操作。在确认 channel 的当前版本并针对受影响 cohort 中的设备测试了恢复路径之前，请保持该事件处于开启状态。

仅在确定要恢复到内置版本时才使用它。这会将设备指向原生 App 内置的 Web 构建版本，该版本可能与上一个 OTA bundle 不同。在将其作为恢复步骤之前，请务必检查兼容性及对用户的影响。

除非您的保留流程另有规定，否则请保留导致故障的 bundle 以供分析。Release ID 和 commit 有助于工程师将变更与稳定版本进行对比。在清理之前请保留相关 logs，特别是如果您需要排查问题为何逃过了测试。

Rollback 并非解决所有故障的万能药。如果根本原因是服务端依赖，请修复该服务。如果变更依赖于已安装二进制文件中缺失的 code，请准备 Native Build 并按照 App Store 的发布流程进行更新。

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

在执行 Pause 或 Rollback 后，应通过观察设备实际状态来验证，而不是仅凭控制台的操作变更就认为已恢复。首先检查 active channel 的状态，然后对比受影响版本与稳定版本在更新采用率、错误率及设备报告方面的差异。

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

测试失败的用户路径。下载成功并不代表 App 运行正常。打开相关页面，重复导致报错的操作，并验证 App 是否达到预期状态。如果故障涉及核心业务流，请让非变更人员进行结果确认。

进行同类对比。错误总数上升可能与发布无关，例如服务问题或流量变化。在支持的字段中，按 bundle、channel、App 版本和设备进行过滤。寻找与发布相关的差异，而不是默认归咎于最新的 update。

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

记录恢复结果和剩余的不确定性。如果错误率下降但仍有少数用户报告相同问题，在搞清楚他们是处于离线状态、使用了旧版 Native Build，还是仍在运行受影响的 bundle 之前，请勿关闭该 incident。

当 Channel 指向预期的版本，且能复现问题的设备上故障用户路径恢复正常时，即可确认恢复成功。指标数据能帮你洞察问题的规模，而设备检查则能确认用户的实际体验。

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

在发布前，将暂停（pause）和回滚（rollback）纳入发布计划。发布负责人应明确谁有权停止曝光，以及谁有权批准恢复到稳定版本。这能消除常见的延迟：避免在等待会议期间，又有更多设备进入 rollout 范围。

在测试 rollout 目标时，请始终保留一个稳定的回退版本。先针对一小部分定义的受众进行测试，只有在约定的健康指标保持在阈值内时才扩大范围。Capgo 支持基于 Channel 的发布控制，让团队能够将测试与大规模生产交付分离。

将发布检查集成到 CI/CD（运行测试并部署变更的自动化流程）中。Pipeline 可以在测试通过后将 bundle 发布到目标 Channel。如果 Channel 错误或发布尚未准备好进行升级，Pipeline 也应能安全地触发失败。

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

通过 Capgo，只需一条命令即可将 bundle 发布到指定 channel。请将该命令集成到包含检查环节的发布流程中，并在发布记录中明确目标 channel。这能帮助值班工程师准确识别发布内容，无需猜测究竟是哪个 lane 接收了更新。

在启用自动防护机制前，请先定义触发信号及对应的执行动作。Pause（暂停）可以在停止新用户接触的同时，让当前已覆盖的用户保持在目标版本；而 Rollback（回滚）则会将设备导向稳定版本。这两者的结果截然不同，请勿混淆配置。

使用测试 channel 来演练完整的响应流程。发布一个无害的变更，验证 pause 控制是否生效，随后测试回滚到上一个 bundle。在每次操作后，务必在真机上确认 App 行为。编写好的 runbook 应包含 channel、命令或 dashboard 路径、预期状态以及确认成功的负责人。

Release notes 应明确标识 bundle 及其用途。保持发布记录与源码变更之间的关联，以便在出现错误时工程师能快速缩小搜索范围。如果你的团队需要跨时区交接故障处理，请务必注明最后执行的操作以及下一阶段的决策负责人。

如果故障指向更广泛的前端实现瓶颈，那么像如下 Web 开发人员： Amir Arezoo 可能对网站开发工作有所帮助。这与 Capgo 的 rollout 控制是分开的，后者专门负责兼容 App 更新的交付与恢复。

到目前为止，你的发布流程应包含稳定的回退方案、负责人、停止规则以及经过测试的恢复操作。保持工作流足够简洁，以便值班工程师在压力下也能快速执行。

常见问题

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

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

我应该选择暂停还是回退？

当问题仍在调查中且需要限制影响范围时，请选择暂停。当已知目标版本会损害用户体验，或受影响设备需要稳定 bundle 时，请选择回退。Capgo pause rollout vs rollback 的选择取决于你的首要需求是控制风险还是恢复现有 cohort 的状态。

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

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

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

不。OTA rollback 可以恢复到之前的可更新 web bundle，但无法在已安装的应用二进制文件中添加或删除原生 code。如果问题源于原生 plugin 或 app-shell 的变更，请评估是否需要进行新的 Native Build。首先要确定是哪一层导致了故障。

暂停或 rollback 之后我该检查什么？

确认 channel 的状态和当前活跃的 bundle，然后按版本检查更新采用率和错误率。在受影响群体的设备上测试失败的用户路径。同时也要检查尚未更新的设备，因为整体指标可能会掩盖仅限于某个版本或特定群体的特定问题。

总结

在调查期间需要停止新用户接触时，请使用 Pause。当目标用户需要稳定版本时，请使用 Roll back。提前配置好这两种控制手段，并在下次生产环境发布前，先在测试 channel 上进行演练。