来自 Coroid 的 pull request 在您看到它之前已经过验证。本节将介绍其含义及配置方法。
各个层级
验证并非单一流程，共包含四个层级，每个层级对应不同的问题。
您的测试套件。这是最可靠的验证信号，因为它已体现团队认定的关键要求。Coroid 会在每个任务中于干净的工作空间内运行该套件。
质量门控。基于策略定义的检查项：代码覆盖率、代码规范检查、安全扫描、浏览器测试，以及全球化检查用于多语言项目。阻塞性门控会阻止任务继续；建议性门控仅记录发现结果并允许任务继续执行。详情请参阅质量策略与门控。
审核。审核代理会读取已完成的代码差异并生成相关发现结果。可修复的发现结果会退回给开发人员重新处理；其余结果则会附加到 pull request 上。
验证依据。预览部署结果、扫描结果及代码覆盖率差异均会附加在 pull request 上，因此验证信息会与代码一同呈现。详情请参阅审核验证依据。
- 您的测试套件该变更会破坏现有功能吗？
- 质量关卡它符合既定规范的要求吗？
- 评审细心的代码审阅者会接受它吗？
- 佐证材料相关证明已附在代码旁了吗？
- 您的评审这是应当做出的正确变更吗？
每个自动化层级都会在pull request生成前运行，因此失败结果会作为返工内容反馈到运行流程中。
验证所能证明及无法证明的内容
验证可确认变更符合预期功能、不会破坏现有功能，且满足设定的标准。
它能不能证明该变更是值得开发的。这一点由需求说明中所规定的验收标准以及您的审核流程来判定。
即便通过所有层级的验证，变更仍可能是错误的。清晰区分这一点才能确保整个流程的可信度——一旦将验证等同于最终判定，人们便不会再认真审核。
提前运行验证的意义
在 pull request 生成前，各层级便会先运行验证，这样失败结果会作为重新处理任务返回，而非形成您最终会拒绝的 pull request。
在工作空间内发现问题是比在屏幕上看到问题成本更低。您的审核应是首次人工审视，而非初次查看。
入门指南
如果您是首次配置此项功能：
- 请确保您的测试套件能正常运行——详情请参阅 构建与测试配置。若这一步出错，其他设置都无关紧要。
- 在您的标准级别设置组织默认策略，无需采用最严格的标准。
- 关联您已在使用的验证依据提供方。
- 逐一添加门控，优先添加建议性门控。