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