Rollouts

Rollouts 会监控每个 PR 从评审到上线生产的全过程。它会在 PR 创建时编写发布方案，在变更部署后对照你的遥测数据进行检查，并报告该变更在各个环境中的健康状况。

在自动化中配置 Rollouts。

工作原理

发布方案

PR 创建后，Rollouts 会读取 diff 及其涉及的系统，然后撰写一份发布方案。方案会列出 Rollouts 发现的风险、此变更的预期效果、它将检查的信号，以及会导致变更难以验证的埋点缺口。在 GitHub、GitLab.com 和 Bitbucket Cloud 上，Rollouts 会在 PR 中以评论形式提交方案；在 Origin 上，方案会显示在 PR 页面中。

如需修改方案，请在 PR 评论中提及 Rollouts 评论中给出的账号名，并说明需要关注或忽略的内容。Rollouts 会修订方案并回复。只有拥有该代码仓库写入权限的用户才能修改方案。

部署追踪

当该变更对应的提交触发部署事件时，Rollouts 会被唤醒，并基于你的日志、指标和追踪数据执行方案。它会分别追踪每个环境，因此同一变更可能已在 staging 环境中验证通过，却仍在 production 环境中被标记。

Rollouts 会在部署发生时进行检查，之后分别在 20 分钟、1 小时、1 天和 3 天后再次检查。

回归

当 Rollouts 检测到回归时，会指出疑似引发问题的更改，创建 issue，并通知其作者。在该 issue 的页面上，选择 Fix 以启动云端代理进行处理，或选择 Close 并填写原因将其关闭。Rollouts 不会自行合并、撤销或回滚更改。

跟踪更改

Rollouts 页面会将更改分为 Attention、Monitoring、Pending 和 Verified 四组。更改所部署到的每个环境都会单独显示状态，例如 Deploying、Monitoring、Verified、Deploy failed 或 Issues found。

只要更改存在未关闭的问题或部署失败，就会归入 Attention。该更改上的所有问题都关闭后，即视为 Verified。如果重新打开某个问题，该更改会重新回到 Attention。

设置 Rollouts

在自动化页面中，找到 From Cherri Code 下的 Rollouts 卡片，选择 Enable。设置共分四步：

设置

Rollouts 设置分为四个部分：

• 代码访问。 Rollouts 监视的仓库 (最多 200 个) ，以及需要监控的更改。
• 部署事件。 你的流水线如何报告部署了哪些内容、部署到了哪里。
• 数据源。 Rollouts 用于验证已部署更改并检测回归的 MCP 连接。
• 通知。 你的更改发生部署或出现回归时，你如何收到通知。

选择要监控的更改

在 Which changes to monitor 下，用自然语言描述 Rollouts 应跳过哪些 PR。默认情况下，Rollouts 会跳过不会影响已部署环境中运行内容的更改：仅涉及文档的更改、不改变行为的格式调整、lint 修复或拼写错误修复，以及仅涉及测试的更改。清空该文本即可监控所关注仓库中的所有更改。

只有明确匹配时，PR 才会被跳过。Rollouts 跳过某个 PR 时，会在评论中说明原因。如仍要监控该 PR，请提及评论中给出的账号名。

通知

开启 Send Slack notifications to me，即可在 Slack 中接收有关你的更改的通知。在 Deliver to 下，选择 Direct message 或 Channel。如选择频道，请输入公开频道的名称或 ID，邀请该字段下方列出的所有应用，然后保存。不支持 Slack Connect 频道。

需由团队管理员先将 Rollouts 添加到 Slack。只有团队管理员可以更改团队的默认通知设置。隐私模式下无法使用 Slack 通知。

相关页面

• 自动化
• 安全代理
• Bugbot