低尝试阈值可能会暂停健康的OTA升级。高阈值可能会让坏的包裹到达太多设备。 Capgo 自动暂停最小尝试次数 setting controls when Capgo has enough install and failure data to pause a channel. Use the steps below to set it with care, test it, and connect it to your release flow.
目录
- 步骤 1: 理解最小尝试次数的控制
- 步骤 2: 在 Capgo 中找到自动暂停设置
- 步骤 3: 选择一个安全的最小尝试次数值
- 步骤 4: 测试自动暂停的频道
- 步骤 5: 监控尝试次数、分析和自动回滚
- 步骤 6: 在 CI/CD 中自动化设置
- 常见问题
- 结论
步骤 1：了解最小尝试次数的控制
这个 自动暂停最小尝试次数 值设置了 Capgo 需要暂停规则生效之前的最小样本数量。它是一个门槛，而不是失败次数限制。该设置告诉 Capgo 等待足够的更新尝试存在之前，不要判断发布。
一个尝试可以包括设备尝试安装一个包。尝试可能成功或失败。具体结果取决于更新路径、应用状态和更新器配置。因此，值应该与发布规模一起考虑。
Capgo 的频道参考描述auto-pause-min-attempts最小安装次数加失败尝试次数的最小值，才会触发自动暂停。该字段在 CLI 参考中以字符串形式表示，因此请确保值符合命令或 API 的期望格式。您可以在更改实时频道之前 Capgo 频道 CLI字段 将此设置视为最小证据规则。值为 1 可能在第一次记录的尝试后立即反应。这样可以在内部测试非常小时有所帮助，但也可能对一个坏的网络会话反应。较大的值可以让发布更多时间收集有用的样本。
从用户中分离尝试次数
结论
尝试次数与独特的用户不同。一个设备可能会重试更新。一个用户可能会在多个设备上运行应用程序。您的分析视图也可能以与您自己的产品指标不同的方式组合事件。
在选择数字之前，请写下您希望阈值保护什么。如果目标是尽早捕捉到破碎的 JavaScript 包，一个小的受控通道可以使用较低的值。如果目标是保护广泛的生产发布，则需要足够的尝试次数，以避免基于一个设备或一个短暂停机的情况下的决策。
- 对于私有测试通道，请使用较小的阈值。
- 当通道具有混合网络和设备类型时，请使用较大的阈值。
- 如果短暂停机导致了假停机，请提高阈值。
- 只有当假停机的成本高于延迟检测的成本时才降低阈值。
自动暂停应该停止发布。它不应该取代包评审、设备测试或清晰的回滚计划。将阈值视为您的发布过程中的一个控制项。
关键 takeaway: 最小尝试次数控制了发布证据Capgo需要多少才能让其自动暂停策略生效。
步骤 2：在Capgo中找到自动暂停设置
要设置 Capgo 首先找到分发包的频道。自动暂停属于发布控制的一部分，因此更改应用级更新器配置可能不会更改您期望的频道策略。
从Capgo控制台开始，或者使用频道命令和API路径，团队已经使用。检查频道名称之前不要编辑任何内容。测试频道和生产频道可能具有相似的名称，一旦在错误的频道上设置了正确的值，就会发生发布意外事件。
在频道设置中查找自动暂停字段。相关字段可能包括最小尝试值和置信度设置。将这些字段放在一起进行更改审查。最小样本表明Capgo何时判断发布。置信度值会影响信号强度必须达到什么样的程度才能暂停。
通过可审计的路径设置值
使用控制台进行快速控制的更改时，使用CLI，团队记录控制台更改。使用CLI时，设置属于发布脚本的设置。使用公共API时，服务管理频道策略作为更广泛的部署系统的一部分。
无论您选择哪个路径，都要先捕获旧值。保存频道名称、包版本、发布状态和新值在同一更改记录中。这会给您一个清晰的答案，如果频道后来暂停。
对于API驱动的工作流程，Capgo通过其公共API公开频道资源。 Capgo 频道 API 文档 这是检查字段名称和请求形状的地方，而不是猜测从本地脚本。
当您编辑值时，请以整数形式输入，因为字段期望这样。不要添加百分比符号。不要使用小数。如果您的工具存储配置为 JSON，请保持关键字的准确拼写并保留当前 Capgo 参考中显示的字符串格式。
确认更改
保存后再次阅读频道。不要假设成功的命令意味着意图的字段已更改。验证返回的频道数据或仪表板值。
然后问三个问题：
- 设置是否在预期频道上更改了？
- 频道是否仍指向预期的包？
- 滚动是否处于活动状态、暂停状态或已完成状态？
如果值未出现，请停止。检查权限、字段拼写和频道标识符。报告成功但未验证保存状态的部署脚本难以信任。
步骤 3：选择安全的最小尝试次数值
选择 Capgo 自动暂停最小尝试次数值，从滚动的大小和风险中选择。没有适用于每个应用程序的安全数字。正确的阈值为政策提供了足够的证据，同时仍然能够早期检测到坏的更新。
从最小的组开始，才能给你有用的信息。私有频道可能包含已知应用版本的内部设备。生产频道可能包括较旧的设备、弱连接和每隔几天才打开应用的用户。这些组不应默认共享相同的阈值。
使用简单的决策规则
问问你需要多少次尝试才能让失败模式变得有意义。如果你的测试频道只有几台设备，一高阈值可能在测试窗口内永远不会被触及。如果你的生产频道在几分钟内接收到大量尝试，一很低阈值可能会在短暂的网络问题后暂停发布。
设置一个较低的值时：
- 频道是私有的。
- 包更新了一个高风险功能。
- 你需要在阶段测试期间快速获得反馈。
- 你的团队可以在发布后不久检查每个故障。
设置一个较高的值时：
- 频道服务的设备组合较广。
- 用户通过不稳定的网络连接。
- 应用的日常打开频率较低。
- A短暂停机可能会产生许多假失败。
不要使用阈值来隐瞒已知问题。如果一个捆绑包在必需的原生插件上失败，自己暂停发布并修复原因。最小尝试次数设置不能使不兼容的捆绑包安全。
配对阈值与发布大小
假设您首先将发布推送到一个小型内部频道。您可能会选择一个阈值，让团队在自动暂停可以采取行动之前看到几次安装结果。一次捆绑包通过该阶段后，移动它到一个更广泛的频道，阈值反映了更大的样本。
这种方法保持了第一个信号的快速响应，而不要求生产政策对一个小样本做出反应。它还给您一个明确的地方来调整设置。改变阈值与频道一起进行，而不是在发布已经失败后。
跟踪发布记录旁边的值。写下您为什么选择它，什么会使您改变它，以及谁可以批准该改变。这在团队成员在事故期间看到暂停的频道时很重要，需要快速获取上下文。
Pro Tip： 从一个受控频道开始，记录尝试次数，然后根据观察到的发布行为而不是猜测来调整生产阈值。
步骤 4：使用频道进行发布测试
测试频道中的自动暂停之前不要依赖它。频道给您一个测试的边界。您可以将捆绑包发送到一个已知的组，观察尝试次数的增加，并确认当政策达到阈值时会发生什么。
首先，创建一个可以识别的测试包，不要与发布包混淆。保留code的更改。测试应该证明发布控制，而不是创建第二个应用程序问题。
接下来，分配一小组测试设备到频道。检查每个设备都有预期的本机应用程序版本。OTA code不能修复每个本机不匹配，所以运行错误二进制的设备可能会使测试难以阅读。
发布包到频道。尽可能使用一个命令在正常Capgo部署流程中，但保留包和频道ID在发布日志中。不要依赖终端滚动缓冲区在事故期间。
测试暂停路径
您需要一个安全的方式来产生失败的尝试。使用测试包或受团队批准的控制失败条件。永远不要损坏生产包，只为了看看自动暂停是否有效。
观察以下序列:
- 频道指向测试包。
- 设备接收更新指令。
- 尝试出现在分析视图中。
- 达到最小尝试次数。
- 失败信号导致频道暂停，如果政策条件被满足。
第五步很重要。达到最小尝试次数可能使自动暂停有效。它并不意味着每次发布都在该精确计数时暂停。其他政策字段和观察到的结果可能会影响结果。
测试恢复
暂停后确认用户接收到的内容。检查失败的包是否仍被选中，新设备是否停止接收它，是否可以回滚到之前的安全包。答案取决于您的更新器和频道设置，因此请通过应用日志来验证，而不是假设。
然后在有人复核失败后，仅在已知良好的包上恢复。如果失败来自于一个坏的构建，创建一个新的包。不要简单地推送相同的artifact并希望下一次尝试会表现出不同。
记录测试结果。包括阈值、设备数量、失败条件、暂停时间和恢复动作。这使得一次性测试变成可重复的发布检查。
步骤 5：监控尝试、分析和自动回滚
监控告诉您Capgo 自动暂停最小尝试规则是否看到一个健康的发布还是一个破碎的发布。观察尝试次数和失败行为。一个没有上下文的计数可能会导致您在开始太早或错过一个不断增长的问题。
使用Capgo Observe 来检查更新活动和发布状态。 Capgo Observe 文档 描述了用于查看更新信息并配置自动暂停行为的区域。保持仪表板打开，特别是在发布的第一部分，尤其是当包改变启动code 或核心应用流时。
一起阅读信号
首先查看尝试次数。然后检查失败次数和时间模式。稳定的成功安装流程与一次bundle激活后爆发的失败流程是不同的。
当可用时，检查设备和应用程序版本的详细信息。如果失败集中在一个本机版本上，OTA包可能需要一个更新的二进制文件。如果失败出现在每个版本上，请检查包本身或更新服务路径。
网络故障可能会产生噪音。短暂的停机可能会产生失败的尝试而没有code缺陷。这就是为什么阈值应该与信心政策和人工审查过程一起工作的原因。自动暂停可以停止暴露，但它不能解释每个失败。
了解在您的流程中什么是回滚
回滚会将受影响的用户推回一个已知的良好版本或停止坏版本从达到更多设备。它不能修复缺乏必需功能的本机二进制文件，也不能撤销OTA包已经运行的数据迁移。
在生产使用之前，确认回滚路径与测试通道。验证哪个包被视为安全。检查设备在暂停期间是否脱机。然后编写恢复步骤，以便on-call工程师可以找到它们。
Capgo的 回滚文档 可以帮助您将可用的回滚控制映射到您的通道计划中。使用文档行为作为参考，因为结果可能取决于更新器版本和发布设置。
发生故障时，如果故障模式已清晰，首先暂停，然后检查日志和包变更。花费几分钟停止暴露通常比让已知的坏版本继续传播更容易管理。
步骤 6：在 CI/CD 中自动设置
将 Capgo 自动暂停最小尝试次数值放入您的发布工作流程中，当设置与每个频道更改时。自动化可以移除手动漂移。它还使选择的阈值在 code 审核中可见。
频道策略应与机密信息分开。频道名称、发布阶段和最小尝试次数值可以存储在版本化配置中。 API 令牌必须存储在 CI/CD 秘密存储中。不要将令牌提交到仓库，只因为频道设置已经存在。
发布作业应遵循清晰的顺序：
- 构建 Web 包。
- 运行测试并检查原生兼容性。
- 上传包。
- 设置或确认目标频道。
- 应用最小尝试次数值。
- 验证保存的频道状态。
- 发布或推进发布。
使用dry-run或review阶段，如果您的部署系统支持的话。review阶段应该显示bundle标识符、渠道、阈值和发布动作，直到生产步骤运行之前。
将验证作为工作的一部分
命令完成后API或CLI，重新获取渠道状态。如果返回的值与预期配置不符，则失败该工作。这可以捕捉到错误的渠道ID、拒绝的字段和部分更新。
环境变量是将发布设置传递到CI工作的一个常见方式。工作可以读取渠道名称或阈值而不将机密信息放在源文件中。请确保变量名清晰并在部署前验证它们。
例如，工作流可能需要：
CAPGO_CHANNEL为目标渠道CAPGO_MIN_ATTEMPTS为已批准的阈值CAPGO_BUNDLE_ID为上传的包
这些名称是工作流约定，而不是Capgo字段名称。将它们映射到一个地方的确切CLI或API字段。这使得未来修改更容易审查。
为了进行更深入的安全检查，请查看Capgo关于在CI/CD管道中安全OTA更新的指南。重要的习惯很简单：限制令牌访问，记录发布决策，并在每次更改后验证结果。
保持变更记录
将阈值与提交或发布ID一起存储。添加变更原因。如果发布暂停不期望，比较策略与包和部署时间可以帮助你
Capgo 以组织为单位计费，提供 14 天的免费试用期，而不是一次性零售购买。这种模式适用于那些想在测试发布流程之前将其纳入他们的常规交付过程的团队。保持试验工作的集中性：配置一个通道，运行一个暂停测试，验证一个回滚路径。
一个命令可以发布更新。安全的工作流程是同时检查通道、跟踪采用和留下回滚路径的工作流程。
FAQ
什么是 Capgo 自动暂停最小尝试次数的含义？
Capgo 自动暂停最小尝试次数设置了自动暂停策略可以采取之前的最小安装和失败尝试次数。它是一种样本大小门槛，而不是失败安装百分比。一个较低的值会更快地反应，但可能依赖于较少的证据。一个较高的值会给通道更多的时间来收集结果。
在 Capgo 中哪里设置自动暂停最小尝试次数？
您可以在 Capgo 控制台、 CLI 或公共 API 中设置值，然后读取通道以确认保存的字段。首先检查通道名称。编辑测试通道时，生产通道不会改变生产发布。
什么是安全的最小尝试次数值？
安全的值取决于通道大小、设备混合、网络质量和发布风险。对于受控测试通道使用较小的阈值，对于广泛的生产发布使用较大的阈值。从已知组开始，观察尝试量，并根据观察到的行为进行调整。
是否达到最小尝试值时总是会暂停发布?
不。达到Capgo最小尝试值使发布可自动暂停，但其他策略条件仍然重要。失败信号、信心设置、通道状态和更新流程都可能影响结果。测试完整暂停路径之前，请在生产环境中使用安全包。
是否可以用自动暂停代替回滚计划？
不。自动暂停停止或限制进一步暴露，而回滚将用户转向可知的良好包时可用。测试两种控制。还要记住，OTA回滚不能添加已安装应用程序没有的本机能力。
Conclusion
设置最小尝试值每个通道，而不是习惯。从小规模测试发布开始，验证暂停和回滚路径，然后在CI/CD中自动批准设置。如果您想测试工作流程，请尝试Capgo在一个通道和一个受控包上，然后扩大发布。
