较低的尝试次数阈值可能会导致健康的 OTA 发布被暂停；而过高的阈值则可能让有问题的 bundle 覆盖过多设备。Capgo 的 自动暂停最小尝试次数 设置项会在 Capgo 收集到足够的安装与失败数据时，自动暂停某个 channel。请参考以下步骤进行谨慎设置、测试，并将其接入您的发布流程。
目录
- 步骤 1：理解 Minimum Attempts 的控制逻辑
- 步骤 2：在 Capgo 中找到 Auto-Pause 设置
- 步骤 3：选择安全的最小尝试次数值
- 步骤 4：通过基于 Channel 的发布测试 Auto-Pause
- 步骤 5：监控尝试次数、分析数据及自动回滚
- 步骤 6：在 CI/CD 中实现设置自动化
- 常见问题
- 总结
步骤 1：了解 Minimum Attempts 的控制机制
该 自动暂停最小尝试次数 该值设定了 Capgo 在触发暂停规则前所需的最小样本量。它是一个门槛，而非失败限制。该设置会告知 Capgo 在判断发布状态前，先等待足够的更新尝试次数。
一次尝试可以包含设备尝试安装 bundle 的过程。尝试可能会成功或失败，具体结果取决于更新路径、应用状态以及 updater 配置。因此，在设定该值时，应结合您的发布规模进行考虑。
Capgo 的 channel 引用描述了auto-pause-min-attempts作为 auto-pause 生效前，安装加失败尝试的最小次数。该字段在 CLI 参考文档中以字符串形式表示，因此请保持其符合命令或 API 要求的格式。你可以查看 Capgo channel 的 CLI 字段 后再修改 live channel。
可以将此设置视为一种“最小证据规则”。设置为 1 时，可能在记录到第一次尝试后就触发。这在极小规模的内部测试中很有用，但也可能因为一次糟糕的网络会话而误触发。较大的值能为 rollout 提供更多时间来收集有效的样本。
区分用户与尝试次数
尝试次数并不等同于独立用户。一台设备可能会多次重试更新；一名用户也可能在多台设备上运行 App。此外，你的 analytics 视图对事件的分组方式可能与你的产品指标有所不同。
在确定数值之前，先明确你希望该阈值保护什么。如果目标是尽早发现损坏的 JavaScript bundle，可以使用较小的受控 channel 并设置较低的阈值。如果目标是保护大规模的 production release，则需要足够的尝试次数，以避免仅基于单台设备或短期停机而做出决策。
- 对于私有测试 channel，请使用较小的阈值。
- 当 channel 涉及多种网络环境和设备类型时，请使用较大的阈值。
- 如果短期停机导致了误触发 pause，请提高阈值。
- 只有当延迟检测的代价高于误触发 pause 的代价时，才考虑降低阈值。
Auto-pause 应当用于停止发布，但不应取代 bundle 审核、设备测试或明确的回滚计划。请将该阈值视为发布流程中的一项控制手段。
核心要点： Minimum attempts 用于控制 Capgo 在触发 auto-pause 策略前需要收集多少发布证据。
第 2 步：在 Capgo 中找到 Auto-Pause 设置
若要设置 Capgo auto pause minimum attempts 的值，请先找到推送 bundle 的 channel。Auto-pause 属于发布控制范畴，因此更改应用级的 updater 配置可能无法达到您预期的 channel 策略效果。
请从 Capgo dashboard 开始，或使用您的团队已有的 channel 命令和 API 路径。在进行任何编辑前，请务必检查 channel 名称。测试 channel 和生产 channel 的名称可能非常相似，在错误的 channel 上设置正确的值，依然会导致发布事故。
在 channel settings 中查找 auto-pause 相关字段。相关字段可能包括 minimum attempts 值和 confidence 设置。在进行变更评审时，请将这些字段放在一起查看。Minimum sample 决定了 Capgo 何时可以对发布进行判断；而 confidence 值则会影响触发 pause 所需信号的强度。
通过可审计的路径设置该值
如果您需要快速进行受控变更，且团队会记录 dashboard 变更，请使用 dashboard。如果该设置属于 release script 的一部分，请使用 CLI。如果服务作为更广泛部署系统的一部分来管理 channel 策略，请使用公开的 API。
无论选择哪种方式，请先记录旧值。在同一条变更记录中保存 channel 名称、bundle 版本、rollout 状态和新值。这样如果 channel 随后暂停，您就能得到明确的答案。
对于由 API 驱动的工作流，Capgo 通过其公开的 API 暴露 channel 资源。该 Capgo channel API 文档 是检查字段名称和请求格式的最佳场所，不要仅凭本地脚本进行猜测。
编辑数值时，请按字段要求输入整数。不要添加百分号，也不要使用小数。如果您的工具将配置存储为 JSON，请确保 key 的拼写完全一致，并保留当前 Capgo 参考中显示的 string 格式。
确认变更
保存后请再次读取 channel。不要认为命令执行成功就意味着目标字段已更改。请验证返回的 channel 数据或 dashboard 数值。
然后问自己三个问题：
- 设置是否已在目标 channel 上更改？
- channel 是否仍指向预期的 bundle？
- rollout 是处于 active、paused 还是 complete 状态？
如果该值未出现，请立即停止。检查权限、字段拼写以及 channel 标识符。如果部署脚本在未验证保存状态的情况下就报告成功，是很难让人信任的。
步骤 3：选择合理的最小尝试次数
根据 rollout 的规模和风险，选择合适的 Capgo auto pause 最小尝试次数。没有适用于所有 App 的安全数值。合理的阈值既能为策略提供充足的证据，又能尽早检测到错误的 update。
从能提供有效反馈的最小群体开始。私有 channel 可能只包含已知 App 版本的内部设备；而生产 channel 可能包含旧设备、弱网环境以及几天才打开一次 App 的用户。默认情况下，这些群体不应使用相同的阈值。
使用简单的决策规则
思考在失败模式具有统计意义之前，你需要多少次尝试。如果你的测试 channel 只有少量设备，高阈值可能在测试窗口期内永远无法达到；如果你的生产 channel 在几分钟内就会收到大量尝试，过低的阈值可能会在短暂的网络问题后就暂停发布。
在以下情况下设置较低的值：
- Channel 是私有的。
- Bundle 修改了高风险功能。
- 在分阶段测试期间需要快速反馈。
- 团队可以在发布后迅速检查每一次失败。
在以下情况下设置较高的值：
- 该 Channel 覆盖了多种类型的设备。
- 用户可能通过不稳定的网络进行连接。
- 应用的日启动频率较低。
- 短暂的网络中断可能会导致大量误报失败。
不要利用阈值来掩盖已知问题。如果 bundle 因必需的 native plugin 失败，请手动暂停发布并修复原因。设置最小尝试次数无法让不兼容的 bundle 变得安全。
将阈值与发布规模配合使用
假设你先向小型内部 Channel 发布。你可以选择一个较高的阈值，让团队在 auto-pause 生效前看到几次安装结果。一旦 bundle 通过该阶段，再将其移至更广泛的 Channel，并使用反映更大样本量的阈值。
这种方法既能保证首个信号的快速响应，又不会让生产策略对极小样本做出反应。它还为你提供了明确的设置调整点。应随 Channel 调整阈值，而不是在发布失败后才去调整。
在发布记录旁记录该值。写下选择它的原因、触发变更的条件以及谁有权批准变更。当团队成员在事故期间看到 Channel 被暂停并需要快速了解上下文时，这至关重要。
专家提示： 从受控 Channel 开始，记录其尝试次数，然后根据观察到的发布行为而非凭空猜测来调整生产环境的阈值。
步骤 4：通过基于 Channel 的发布测试 Auto-Pause
在生产环境正式启用前，先在 Channel 上测试 auto-pause 功能。Channel 为测试提供了边界。你可以向特定用户组发送 Bundle，观察 Attempt 次数上升，并确认当策略达到阈值时会发生什么。
首先，制作一个易于识别的测试 Bundle，避免与正式版本混淆。确保 code 的改动是安全的。测试的目的是验证发布控制逻辑，而不是制造第二个 App 问题。
接下来，为该 Channel 分配一小部分测试设备。检查每台设备是否运行着预期的 Native App 版本。OTA code 无法修复所有的 Native 版本不匹配问题，因此运行错误二进制文件的设备可能会干扰测试结果。
将 Bundle 发布到 Channel。尽可能在常规的 Capgo 部署流程中使用单条命令，但务必在发布日志中记录 Bundle 和 Channel ID。在处理突发故障时，不要依赖终端的滚动缓存。
测试暂停路径
你需要一种安全的方式来制造失败的 Attempt。使用仅限测试的 Bundle 或团队认可的可控失败条件。切勿为了测试 auto-pause 是否生效而损坏生产环境的 Bundle。
观察以下流程：
- Channel 指向测试 Bundle。
- 设备接收到更新指令。
- Analytics 视图中出现 Attempt 记录。
- 达到最小 Attempt 次数阈值。
- 如果满足策略条件，失败信号将导致 Channel 进入暂停状态。
第五步至关重要。达到最小尝试次数（minimum attempts）可能会触发自动暂停（auto-pause）。但这并不意味着每次 rollout 都会在达到该数值时精确暂停。其他策略字段和观察到的结果也可能影响最终结果。
同时也要测试恢复流程
暂停后，请确认用户的实际体验。检查失败的 bundle 是否仍处于选中状态、新设备是否已停止接收该 bundle，以及之前的安全 bundle 是否可用于回滚。结果取决于你的 updater 和 channel 配置，因此请通过 app logs 进行验证，不要凭直觉猜测。
在有人复盘失败原因后，仅使用已确认良好的 bundle 进行恢复。如果失败是由错误的 build 导致的，请重新制作一个 bundle。不要只是简单地再次推送同一个 artifact，并寄希望于下次尝试会有不同的结果。
记录测试结果。包括阈值、设备数量、失败条件、暂停时间以及恢复操作。这将一次性测试转化为可重复的发布检查流程。
步骤 5：监控尝试次数、分析数据与自动回滚
通过监控可以了解 Capgo auto pause minimum attempts 规则当前处于健康的 rollout 还是已损坏的状态。请结合失败行为来观察尝试次数。脱离上下文观察次数可能会导致你过早暂停，或者错失正在扩大的问题。
使用 Capgo Observe 来检查更新活动和 rollout 状态。 Capgo Observe 文档 此处用于查看更新信息并配置 auto-pause 行为。在发布初期请保持 dashboard 开启，特别是当 bundle 改变了启动 code 或核心应用流程时。
综合分析各项指标
首先查看尝试总数，然后检查失败次数和时间模式。持续稳定的成功安装与某个 bundle 激活后出现的爆发式失败在表现上截然不同。
在条件允许时检查设备和 app-version 详情。如果失败集中在某个 native 版本，则 OTA bundle 可能需要更新的 binary。如果所有版本都出现失败，请检查 bundle 本身或更新服务路径。
网络故障可能会产生干扰。短暂的断网可能会导致尝试失败，但这并非 code 缺陷。因此，阈值应配合置信度策略和人工审核流程使用。Auto-pause 可以阻止风险扩散，但无法解释每一次失败。
明确回滚在您业务流程中的含义
回滚会将受影响的用户引导回已知的稳定版本，或阻止故障版本触达更多设备。它无法修复缺少必要能力的 native binary，也无法撤销 OTA bundle 已经执行过的数据迁移。
在正式上线前，请先通过测试 channel 确认回滚路径。验证哪些 bundle 会被视为安全版本。检查设备在暂停期间处于离线状态时会发生什么。最后，将恢复步骤记录在值班工程师易于找到的地方。
Capgo 的 回滚文档 可以帮助你根据 channel 方案规划可用的回滚控制。请以文档说明的行为作为参考，因为最终结果可能取决于 updater 版本和发布设置。
发生故障时，如果失败模式很明显，请先执行暂停。然后检查 logs 和 bundle 变更。花几分钟时间停止风险暴露，通常比任由已知的错误版本继续扩散更容易处理。
第 6 步：在 CI/CD 中自动化设置
当不同 channel 的 Capgo auto pause minimum attempts 值不同时，请将其纳入发布工作流。自动化可以消除手动配置偏差，并让选定的阈值在 code 评审中清晰可见。
请将 channel 策略与 secrets 分开。channel 名称、发布阶段和 minimum attempts 值可以存放在版本化的配置中。API tokens 必须保留在 CI/CD secret store 中。切勿仅仅因为 channel 设置已存在，就将 token 提交到代码仓库。
发布任务应遵循清晰的顺序：
- 构建 web bundle。
- 运行测试并检查 native 兼容性。
- 上传 bundle。
- 设置或确认目标 channel。
- 应用最小尝试次数 (minimum attempts) 的值。
- 验证已保存的 channel 状态。
- 发布或推进 rollout 进度。
如果你的部署系统支持，请使用 dry-run 或 review 阶段。在执行生产步骤之前，review 阶段应显示 bundle identifier、channel、threshold 以及 rollout 操作。
将验证环节纳入 Job 流程中
在 API 或 CLI 命令完成后，再次获取 channel 状态。如果返回的值与预期配置不符，则让 Job 失败。这可以捕获错误的 channel ID、被拒绝的字段以及部分更新的情况。
环境变量是将发布设置传递到 CI job 的常用方式。Job 可以读取 channel 名称或 threshold，而无需将 secrets 写入源码文件。请保持变量名清晰，并在部署前进行校验。
例如，你的 workflow 可能需要：
CAPGO_CHANNEL用于目标 channel。CAPGO_MIN_ATTEMPTS用于已批准的 threshold。CAPGO_BUNDLE_ID用于已上传的 bundle。
这些名称是工作流规范，而非 Capgo 字段名。请在统一位置将它们映射到准确的 CLI 或 API 字段。这样在后续变更时更易于审查。
如需更深入的安全检查，请参考 Capgo 关于在 CI/CD pipeline 中保障 OTA 更新安全的指南。核心习惯很简单：限制 token 权限、记录发布决策，并在每次变更后验证结果。
保留变更记录
将阈值与 commit 或 release ID 一并存储，并注明变更原因。如果 rollout 意外暂停，你可以通过对比策略、bundle 和部署时间来进行排查。
Capgo 按组织订阅计费，提供 14 天免费试用，而非一次性买断。这种模式非常适合希望在正式交付流程中集成发布工作流前进行测试的团队。建议试用时保持目标聚焦：配置一个 channel，运行一次 pause 测试，并验证一条 rollback 路径。
仅用一条命令即可发布更新。但更安全的工作流应当同时检查 channel 状态、追踪采用率，并预留 rollback 路径。
常见问题
什么是 Capgo auto pause minimum attempts？
Capgo auto pause minimum attempts 设置了触发 auto-pause 策略前所需的最小安装数和失败尝试数。它是一个样本量门槛，而非失败安装的百分比。设置较低的值可以更早做出反应，但证据可能不足；设置较高的值则能给 channel 更多时间来收集结果。
我在 Capgo 中哪里设置 auto pause minimum attempts？
您可以在交付 OTA bundle 的 channel 上设置该值。通过 Capgo dashboard、CLI 或公开的 API 进行设置，然后读取 channel 以确认字段已保存。请先检查 channel 名称。在生产环境运行时编辑测试 channel，不会影响生产环境的 rollout。
什么样的 minimum attempts 值才是安全的？
安全值取决于 channel 规模、设备构成、网络质量和发布风险。对于受控的测试 channel，请使用较小的阈值；对于大规模的生产 rollout，请使用较大的阈值。建议先从已知用户群开始，观察其 attempt 数量，并根据实际行为进行调整。
达到 minimum attempts 值一定会暂停发布吗？
不会。达到 Capgo minimum attempts 值仅意味着该 rollout 符合 auto-pause 的条件，但其他策略条件仍然有效。失败信号、置信度设置、channel 状态以及 updater 流程都会影响结果。在生产环境依赖此功能前，请先使用安全的 bundle 测试完整的暂停流程。
Auto-pause 可以替代 rollback 方案吗？
不可以。Auto-pause 是停止或限制进一步的暴露，而 rollback 是在可行的情况下将用户引导至已知的稳定 bundle。请同时测试这两种控制手段。另请注意，OTA rollback 无法为已安装的应用添加其本身不具备的 Native 能力。
总结
不要凭感觉设置每个 channel 的最小尝试次数。建议先从小规模测试开始，验证暂停和回滚流程，然后在 CI/CD 中自动化应用经过验证的配置。如果你想测试工作流，可以在扩大发布范围之前，先针对单个 channel 和受控的 bundle 使用 Capgo。
