一个策略策略是一组命名且带版本的质量门控规则。策略会被关联到项目中，而实际执行的是质量门控规则。
关于相关概念——阻塞式与建议式、质量门控在流程中的位置——请阅读质量门控相关内容。本页介绍如何管理它们。
在 中管理它们Quality Control。其列表会展示组织默认策略以及所有项目的关联策略。选择某一策略即可查看新工作是如何被筛选的、每次变更会进行哪些检查、对应的QA级别及检查运行位置，每个策略项都配有开关，切换后即刻生效。确认按钮可撤销更改，某行设置会决定该检查的具体执行方式。
- 组织默认配置3 个项目正在采用此配置2 / 5
- 门店页面自定义设置4 / 5
- 文档站点遵循默认配置2 / 5
- 计费 API遵循默认配置2 / 5
- 移动应用遵循默认配置2 / 5
- Anti-slop如果变更导致测试用例失效、错误被忽略、占位符被直接发布或产生结构性技术债务，系统会将该变更退回。
- 单元测试系统会在每次变更后，自动查找并运行代码库中的单元测试。
- 浏览器测试2 / 3与默认配置不同系统会针对变更内容执行指定的浏览器操作流程测试。
- 翻译与默认配置不同该检查项会验证变更后的字符串是否已被翻译，同时确认其中的占位符及复数形式是否匹配。
- 代码库校验系统可运行用户自定义的命令，例如代码格式化、文件大小检查、数据库迁移、集成测试以及安全扫描等。
- 全面 QA全面校验开启Thorough QA后，系统会根据规范生成实时的验证证据与截图；若未开启，则采用标准QA流程。
质量控制：现行策略及最新的关卡检测结果。此为示例性数据。
创建策略
策略是一组检查规则，同时会明确标注每项检查失败时是触发阻塞还是仅给出建议。
大多数组织只需要两到三种策略，而非为每个项目单独制定策略：
- 一个严格的生产服务策略
- 一个标准的常规业务策略
- 偶尔还会有一个宽松的内部工具和原型策略
策略数量过多会导致无人能记清哪个项目对应哪种策略。
组织默认策略与项目自身的配置
项目会先遵循组织默认策略，直到你修改其中的某个开关。修改后会为该项目生成独立的配置，该配置会复制自默认策略，后续默认策略的变更不会再影响该项目。某行配置可将某个检查规则从默认策略中复制过来，项目的菜单也可将整个项目重置为组织默认策略。开关背后的完整策略，包括各项要求、检查规则间的依赖关系、修复预算及版本信息，可与高级编辑器从同一菜单中打开。对于遵循默认策略的项目，编辑器会从默认策略的副本开始，除非你发布该副本，否则项目不会发生任何变更。
将默认策略设置为你的标准检查规则，即大多数项目应执行的规则，而非最严格的规则——最严格的规则需由各项目主动选择启用。
拉取请求
人员及其他工具创建的拉取请求会通过 Coroid 的 Coroid GitHub 应用提交至 Coroid。拉取请求在Quality Control模块中决定其处理方式，涵盖组织默认策略及每个项目的对应规则：
- Coroid Quality Control会对每个 pull request 执行上述检查规则，并将结果作为 Coroid Quality Control检查项呈现在 GitHub 上。
- Coroid ReviewCoroid的审核员会逐行阅读 pull request 并针对存疑的代码行发表评论。它会读取经 Coroid Quality Control检查通过的拉取请求。
Coroid Review的设置：
- 其发布内容。默认模式为建议式，仅发表评论且不会导致检查失败。若设为阻塞模式，发现问题时检查即会失败。若希望阻塞式审核能阻止合并操作，需在 GitHub 中将 Coroid Review设为必填检查项。
- 针对哪些拉取请求。默认情况下，它会等待草稿状态标记为就绪后再处理，且会跳过 Coroid 创建的拉取请求，因为 Coroid 的审核员已在任务内部完成审核。它也可跳过机器人提交的拉取请求。
- 审核时机。它会在最后一次代码推送后的静默期结束后才开始审核，默认静默期为五分钟。若有新的推送，尚未开始的审核会被中断。在 GitHub 中重新运行可立即启动审核。
- 审核深度。审核员在一次审核中可阅读和编写的内容范围。
它会遵循 Coroid 的审核规则以及你所在代码库中的review-rules文件夹内的规则。遵循组织默认策略的项目会采用默认设置，与其他管控规则一致。
出现故障时
组织默认策略下有三个开关，可将故障转化为所有项目的后续工作任务。每个开关对应一项自动化流程，可在Factory模块的Automations中查看；该自动化代理会读取代码并创建任务，该任务的流程规范、构建、验证及审核环节与其他任务完全一致。
| 开关 | 触发时机 | 代理执行的操作 |
|---|---|---|
| 任务失败时，创建修复任务 | 任务失败 | 查明原因，若根源在代码中，则创建一个修复该问题的任务。 |
| 部署失败时，展开调查 | 部署失败 | 读取该版本的变更内容，并创建一个任务，说明出错原因及需要修改的部分。 |
| 版本回滚时，规划修复方案 | 版本回滚 | 创建一个任务，记录回滚的内容、原因以及再次发布前必须做出的改动。 |
关闭某个自动化功能会暂停其运行；重新开启则可恢复运行。 每次更改都支持撤销操作。在Factory中，该自动化的页面显示它由Quality Control管理。 在此处暂停其功能与直接关闭它效果相同；修改其指令后需确认才能使其生效，此后该开关将不再具备开启或关闭的功能。
这些原本是新任务中的模板。此前基于某模板创建的自动化功能会继续运行。若从未对其做过修改，开启对应的开关即可接管该自动化功能，无需启动第二个实例。若已对其修改，则该自动化功能仍归您所有：开关所在行会标注其名称，您可将其设为由该开关管理。
安全发布
门控机制的故障并非源于其约束力不足，而是源于善意设置的阻塞型门控会同时阻碍组织内的所有任务。
安全的操作流程：
- 将门控设置为建议模式。
- 让其在实际工作中运行一两周，查看它标记出的内容。
- 根据实践所得的经验调整其配置。
- 升级为阻塞模式在某个项目中应用。
- 确认其运行稳定后再扩大应用范围。
- 1添加关卡预警模式
- 2观察一至两周预警模式
- 3根据触发结果调整关卡设置预警模式
- 4在一个项目中启用阻断模式阻断模式单个项目
- 5更广泛地推广阻断模式更多项目
版本管理与回滚
策略会被版本化管理。每次切换都会生成新版本，通过确认操作即可回滚至上一版本；也可从高级编辑器的版本历史中恢复旧版本。
回滚功能正是您能够放心决定发布策略的原因。若新门控配置不当，回滚只需一步操作，无需进行复杂的排查。
覆盖设置
拥有权限的人员可以覆盖阻塞型门控的设置。覆盖操作会被记录，包括操作者、时间及覆盖对象等信息。
留意门控的覆盖率。若某门控多数情况下都被覆盖，说明它并未起到约束作用，反而只会造成阻碍并留下冗余记录。要么修复该门控，要么直接弃用。