较低的尝试次数阈值可能会暂停正常的 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 涉及多种网络和设备类型时，使用较大的阈值。
- 如果短暂中断导致了误暂停，请调高阈值。
- 只有当延迟检测的代价高于误暂停的代价时，才调低阈值。
自动暂停应能停止发布。它不应替代 bundle 审查、设备测试或明确的回滚计划。请将此阈值视为发布流程中的一个控制点。
核心要点： 最小尝试次数控制 Capgo 在自动暂停策略生效前需要多少发布证据。
第 2 步：在 Capgo 中找到 Auto-Pause 设置
要设置 Capgo 自动暂停最小尝试次数值，请先找到分发 bundle 的 channel。自动暂停属于发布控制，因此修改全局 updater 配置可能不会改变你预期的 channel 策略。
从 Capgo 仪表盘开始，或使用您团队已使用的 channel 命令和 API 路径。在编辑任何内容之前，请检查 channel 名称。测试 channel 和生产 channel 的名称可能非常相似，在错误的 channel 上设置正确的值，仍然是一个等待发生的发布事故。
在 channel 设置中查找自动暂停字段。相关字段可能包括最小尝试次数值和置信度设置。在变更审查中将这些字段放在一起。最小样本量决定了 Capgo 何时可以判断 rollout。置信度值会影响在发生暂停之前信号需要有多强。
通过可审计的路径设置值
当您需要快速受控变更且团队记录仪表盘变更时，请使用仪表盘。当设置属于发布脚本时，请使用 CLI。当服务作为更广泛部署系统的一部分管理 channel 策略时，请使用公共 API。
无论选择哪条路径，请先记录旧值。将 channel 名称、bundle 版本、rollout 状态和新值保存在同一变更记录中。如果 channel 稍后暂停，这将为您提供明确的答案。
对于由 API 驱动的工作流，Capgo 通过其公共 API 暴露 channel 资源。 Capgo channel API 文档 是检查字段名称和请求结构的正确位置，而不是从本地脚本中猜测。
编辑该值时，请输入字段要求的整数。不要添加百分号，也不要使用小数。如果你的工具以 JSON 格式存储配置，请保持键名拼写准确，并保留当前 Capgo 参考文档中显示的字符串格式。
确认更改
保存后重新读取该 channel。不要假设命令执行成功就意味着目标字段已更改。请验证返回的 channel 数据或 dashboard 中的值。
然后问自己三个问题：
- 设置是否在预期的 channel 上发生了更改？
- 该 channel 是否仍指向预期的 bundle？
- Rollout 是处于活跃、暂停还是完成状态？
如果值未出现，请在此处停止。检查权限、字段拼写以及 channel 标识符。一个报告成功但未验证保存状态的部署脚本很难让人信任。
步骤 3：选择安全的最小尝试次数
根据 rollout 的规模和风险，选择 Capgo 自动暂停的最小尝试次数值。没有适用于所有应用的“安全”数字。正确的阈值能为策略提供足够的证据，同时仍能尽早检测到有问题的更新。
从能告诉你有用信息的最小群体开始。私有 channel 可能包含已知应用版本的内部设备。生产 channel 可能包含旧设备、弱连接以及每几天才打开一次应用的用户。默认情况下，这些群体不应共享相同的阈值。
使用简单的决策规则
先想清楚：需要多少次尝试，失败模式才有意义。如果测试渠道只有少量设备，测试窗口内可能永远达不到高阈值。如果生产渠道几分钟内就会收到大量尝试，阈值设得太低，可能因一次短暂网络问题就暂停发布。
以下情况请设置较低的值：
- 渠道是私有的。
- Bundle 改动了高风险功能。
- 在分阶段测试期间需要快速反馈。
- 团队能在发布后很快排查每次失败。
以下情况请设置较高的值：
- 渠道覆盖多种设备组合。
- 用户经常连接不稳定的网络。
- 应用每天打开频率低。
- 短暂故障可能产生大量误报失败。
不要用阈值掩盖已知问题。如果 Bundle 在必需的原生插件上失败，请自行暂停发布并修复原因。最小尝试次数设置无法让不兼容的 Bundle 变得安全。
将阈值与发布规模相匹配
假设你先向小型内部渠道发布。你可以选择一个阈值，让团队在自动暂停生效前看到多个安装结果。一旦 bundle 通过该阶段，将其移至更广泛的渠道，并设置反映更大样本量的阈值。
这种方法让初始信号保持快速，同时避免生产策略对极小样本做出反应。它还为你提供了一个明确的位置来调整设置。随着渠道变化调整阈值，而不是在发布已经失败后再调整。
在发布记录旁跟踪该值。记录你选择它的原因、什么情况下会改变它，以及谁有权批准该变更。当团队成员在事故期间看到暂停的渠道并需要快速了解上下文时，这一点至关重要。
专家提示： 从受控渠道开始，记录其尝试量，然后根据观察到的发布行为而非猜测来调整生产阈值。
步骤 4：通过基于 Channel 的发布测试 Auto-Pause
在生产环境依赖自动暂停之前，先在渠道上测试它。渠道为测试提供了边界。你可以向已知组发送 bundle，观察尝试次数上升，并确认策略达到阈值时发生的情况。
首先，创建一个可识别的测试 bundle，以免与实时发布混淆。确保 code 变更安全。测试应证明发布控制有效，而不是制造第二个应用问题。
接下来，将一小部分测试设备分配到该 channel。检查每台设备是否运行预期的原生应用版本。OTA code 无法修复所有原生不匹配问题，因此运行错误二进制文件的设备可能会使测试结果难以解读。
将 bundle 发布到 channel。在可能的情况下，在常规的 Capgo 部署流程中使用一条命令，但务必在发布日志中记录 bundle 和 channel ID。在事故处理期间，不要依赖终端滚动缓冲区。
测试暂停路径
你需要一种安全的方式来触发一次失败尝试。使用仅限测试的 bundle 或经团队批准的受控失败条件。切勿为了验证自动暂停是否生效而破坏生产 bundle。
观察以下序列：
- Channel 指向测试 bundle。
- 设备收到更新指令。
- Analytics 视图中出现尝试记录。
- 达到最小尝试次数。
- 如果满足策略条件，失败信号将导致 channel 暂停。
第五步很重要。达到 minimum attempts 值后，可能满足 auto-pause 条件。但这不代表每个 rollout 都会在该次数暂停；其他策略字段和观察结果也会影响最终结果。
同时也要测试恢复流程
暂停后，确认用户实际收到什么。检查失败的 bundle 是否仍被选中、新设备是否停止接收它，以及之前的安全 bundle 是否可回滚。结果取决于你的 updater 和 channel 配置，请通过 app logs 验证，不要想当然。
只有在有人复盘失败原因后，才用已确认正常的 bundle 恢复。如果失败来自有问题的 build，请新建 bundle。不要只是再次推送同一个 artifact，指望下次尝试会不一样。
记录测试结果。包括阈值、设备数量、失败条件、暂停时间和恢复操作。这样就把一次性测试变成了可重复的发布检查。
步骤 5：监控尝试次数、分析数据与自动回滚
监控能告诉你 Capgo auto pause minimum attempts 规则看到的是健康的 rollout 还是出问题的 rollout。要结合失败行为观察尝试次数。脱离上下文看次数，可能会让你过早暂停，或错过正在扩大的问题。
使用 Capgo Observe 查看更新活动和 rollout 状态。 Capgo Observe 文档 说明用于查看更新信息并配置 auto-pause 行为的区域。在发布初期请保持 dashboard 打开，尤其是当 bundle 更改了启动 code 或核心应用流程时。
综合解读这些信号
先看尝试总数，再检查失败次数和时间模式。持续的成功安装与某个 bundle 生效后突然出现大量失败，表现完全不同。
在可用时检查设备和应用版本详情。如果失败集中在某个 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 名称、rollout 阶段和 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 流水线中保护 OTA 更新的指南。关键习惯很简单：限制 token 访问权限，记录发布决策，并在每次变更后验证结果。
保留变更记录
将阈值与 commit 或 release ID 一起存储。添加变更原因。如果 rollout 意外暂停，您可以将策略与 bundle 及部署时间进行对比。
Capgo 按组织订阅计费，提供 14 天免费试用，而非一次性零售购买。这种模式适合希望在将其纳入常规交付流程之前，先测试发布工作流的团队。保持试用工作聚焦：配置一个 channel，运行一次 pause 测试，并验证一条 rollback 路径。
一条命令即可发布更新。更安全的流程是同时检查 channel、跟踪 adoption 并保留 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 使用较大的阈值。先从已知分组开始，观察其尝试量，再根据实际表现调整。
达到 minimum attempts 值就一定会暂停发布吗？
不会。达到 Capgo minimum attempts 值只表示该 rollout 满足 auto-pause 条件，其他策略条件仍会起作用。失败信号、置信度设置、channel 状态和 updater 流程都会影响结果。在生产环境依赖它之前，先用安全的 bundle 测试完整的暂停路径。
auto-pause 能替代 rollback 方案吗？
不可以。auto-pause 会停止或限制进一步扩散，而 rollback 在可行时会把用户引导到已知可用的 bundle。请同时测试这两种控制措施。还要记住，OTA rollback 无法为已安装的应用添加它本身不具备的原生能力。
总结
按 channel 设置最小尝试次数，不要凭习惯。先做小规模测试发布，验证暂停和回滚路径，然后在 CI/CD 中自动化已批准的设置。如果想测试工作流，在扩大发布范围前，先用一个 channel 和一个受控 bundle 试试 Capgo。
