Milvus 代码评审机制：sre-robot 自动化门禁、Reviewer/Approver 双审制与 OWNERS 路由

Milvus 采用"自动化 CI 门禁 + 人工双审（Reviewer/Approver）"的 PR 合并机制。本文基于仓库根目录的 CODE_REVIEW.md 展开，结合 OWNERS、OWNERS_ALIASES、CONTRIBUTING.md 与 Makefile 中的真实配置与脚本，讲清一个 PR 从提交到自动合并的完整审查链路，以及评审人在提交前、评审中、写评论时的具体检查清单。读完你既能理解 Milvus 的审查流程设计，也能在本地用 make verifiers 等命令提前自查，减少返工。

一、PR 的自动检查门禁：sre-robot 的四道关卡

Milvus 的所有 PR 都会由 sre-robot 自动检查，只有同时满足以下四个条件才会通过：

1. DCO 检查通过（Developer Certificate of Origin，开发者源许可声明）；
2. 全部测试通过且代码覆盖率检查通过，并打上 ci-passed 标签；
3. Reviewer 通过，打上 /lgtm 标签；
4. Approver 通过，打上 /approve 标签。

其中第二个条件有一个关键细节：如果 commit message 中带有 [skip e2e] 标签，CI 会自动跳过 e2e（端到端）测试，但仍会运行 UT（单元测试）和代码检查器。这个机制在 CODE_REVIEW.md 中出现两次强调，说明它是评审时需要重点关注的点——评审人必须判断"跳过 e2e 是否足够安全"。

从 CI 脚本结构看，ci/jenkins/PR.groovy 定义了一条 4 小时超时的流水线：先执行 make clean && make jobs=8 install USE_ASAN=ON mode=RelWithDebInfo use_disk_index=ON 完成带 ASan 的构建，再按 standalone、distributed-pulsar、standalone-kafka-mmap 三种部署形态的矩阵并行运行 pytest e2e 测试。这解释了为什么 e2e 如此昂贵、也为什么 [skip e2e] 需要评审人谨慎把关。

DCO 的具体要求见 CONTRIBUTING.md：每个 commit message 必须包含 Signed-off-by: Full Name <email> 行，可用 git commit -s 自动追加：

$ git commit -s -m 'This is my commit message'

二、Reviewer 与 Approver：两种角色的职责边界

CODE_REVIEW.md 明确划分了两类角色：

• Reviewer：志愿者制，社区中任何熟悉 PR 所改动包的成员都可以担任。职责聚焦于代码本身——逻辑正确性、错误处理、单元测试覆盖率与代码可读性。
• Approver：关注更宏观的层面——整体设计、代码可读性，以及 PR 是否符合项目行为准则（如标题和 commit message 是否有意义、是否打了正确的 label、注释是否有意义）。目前所有 Approver 都列在 OWNERS_ALIASES 文件中，当前该文件定义了一个 maintainers 别名组，包含 11 位维护者（congqixia、czs007、xiaofan-luan、yanliang567、tedxu 等）。

这种"代码细节 + 流程合规"的分层审查，保证了单个 PR 既有懂业务的人把关实现，又有维护者把关规范与长期维护负担。

三、OWNERS 文件：按路径路由评审人与自动标签

OWNERS 文件定义了评审路由规则，按 glob 模式匹配文件路径，为不同区域指定 reviewers、approvers、required_reviewers 和自动添加的 labels：

路径模式	规则	说明
.*（全局默认）	8 位默认 reviewers，approvers 为 maintainers 别名组	任何文件变更都至少有默认评审池
Makefile$	自动加 area/compilation 标签	构建文件变更归入编译领域
CMakeLists\.txt$	自动加 area/compilation 标签	同上，覆盖 C++ 构建脚本
*\.md$	required_reviewers 为 scsven、XuanYang-cn、xiaofan-luan	文档必须由指定人员评审
codecov.yml$	required_reviewers 为 wangting0128、yanliang567	覆盖率配置变更专人把关
go\.(mod|sum)$	required_reviewers 为 congqixia，加 area/dependency 标签	Go 依赖变更专人把关

这套机制让"谁该看哪类改动"变成声明式配置，而不是靠口头约定：依赖类改动（go.mod/go.sum）必须经过熟悉依赖管理的维护者，文档改动有固定的 required reviewers，构建文件自动打上 area/compilation 标签便于追溯。

四、开始评审之前：Things to do before review

CODE_REVIEW.md 要求评审人先做五件事，再动手看代码：

• 读 PR 的标题、commit message 和关联 issue；如果难以理解，直接要求作者改进表述；
• Bug 修复类 PR：关联 issue 中应有详细的 bug 描述，并确认有测试用例覆盖这个 bug；
• 功能增强类 PR：理解功能的使用场景，确认功能设计合理；
• 性能优化类 PR：确认 PR 中列出了 benchmark 结果；
• 深入思考方案为何必要：是否存在 workaround 或替代方案？

这一步本质是"先审问题定义，再审实现"——很多低质量 PR 的根源不是代码写错了，而是解决了不该解决的问题。

五、评审过程中：Things to check during the review

评审代码本身时，CODE_REVIEW.md 给出了九项检查点：

1. 代码是否符合 style guide？
2. 代码实际行为是否与标题和 commit message 描述完全一致？
3. 能否仅凭函数名和变量名推断其行为？
4. 单元测试是否覆盖了所有重要代码分支？
5. 边界情况和失败处理路径如何？
6. 是否需要更好的分层和抽象？
7. 注释是否足以让人理解代码意图？
8. hack、workaround 和临时修复是否都加了注释说明？
9. 如果打了 [skip e2e] 标签，跳过 e2e 测试是否足够安全？
10. 代码是否会在同一秒内产生大量相似日志？（日志洪泛会掩盖真实错误信息）

最后两项尤其体现 Milvus 这类分布式系统的工程经验：e2e 昂贵但必要，日志洪泛则是线上排障的实际杀手。

对于第 1 项"是否符合 style guide"，仓库提供了可本地执行的检查命令（均来自 CONTRIBUTING.md 与 Makefile）：

$ make fmt            # Go 代码格式化
$ make static-check   # golangci-lint 静态检查（根模块、pkg/、client/、tests/go_client/ 分别执行）
$ make cppcheck       # C++ 格式检查（clang-format）
$ make verifiers      # 一键全量验证：build-cpp + getdeps + cppcheck + rustcheck + fmt + static-check

Makefile 中 verifiers 目标正是这些检查的组合：verifiers: build-cpp getdeps cppcheck rustcheck fmt static-check。此外仓库还提供了 git hooks 在本地自动执行这些检查，见 githooks/README.md：

export GO111MODULE="on"
go get -u github.com/git-hooks/git-hooks
git hooks install

安装后，githooks/pre-commit/fmt 会在每次 commit 时对变更的 .go 文件执行 make fmt，githooks/pre-push/verifiers 会在每次 push 前执行 make verifiers——也就是说，评审清单中"style guide、单测、静态检查"这些硬指标，作者本地就能闭环。

六、写评审评论时的准则：对代码严厉，对作者友善

CODE_REVIEW.md 用一节专门约束评审语气，值得每位开源参与者通读：

• 对作者友善，而不是对代码友善（"Be kind to the coder, not to the code"）；
• 用提问代替断言（"Ask questions rather than make statements"）；
• 对经验较少的贡献者保持尊重、礼让与耐心；
• 当代码质量超出预期时，记得表达赞赏；
• 作者的方案与你不同，并不意味着它就是错的；
• 社区不只是产品，更是人——尽可能帮助他人成长。

这六条把 code review 从"挑错流程"重新定义为"协作与传帮带流程"，也是 Approver 职责中"维护行为准则"的具体化。

七、Approver 的附加职责：PR 形态与提交规范

CODE_REVIEW.md 指出，Approver 除了承担上述 Reviewer 的全部职责外，还必须维护行为准则，具体检查项包括：

• PR 只允许有一个 commit：作者需要在本地仓库完成 squash commit；
• commit message 首字母大写，且不以标点结尾；
• commit message 清晰有意义：只有当标题本身能自解释时，才可以只写标题不带正文；
• PR 关联了正确的 issue：issue 中清楚陈述了要解决的问题和计划方案；
• PR 设置了 kind 标签；
• 源码中变量名可读；非常规缩写必须附带注释说明。

这些要求与 CONTRIBUTING.md 的配套规范形成呼应：单 PR 覆盖率需达到 90% 以上、功能 PR 需按 YYYYMMDD-short-descriptive-name.md 规范提供设计文档（缺失时 Mergify 会打 do-not-merge/missing-design-doc 标签）、接口变更需运行 make generate-mockery 更新 mock。Approver 检查的"PR 形态"问题，多数在 CONTRIBUTING.md 的"Commits and PRs"一节已有前置约定。

八、小结与延伸阅读

Milvus 的评审体系可以概括为三层防线：工具层（DCO、make verifiers、githooks、CI 的 UT+覆盖率门禁）、人工层（Reviewer 盯实现质量，Approver 盯设计与规范）、路由层（OWNERS 按路径声明评审人与标签）。四层标签（ci-passed、/lgtm、/approve 加 DCO）齐备后由 sre-robot 自动合并，最大限度减少人工介入，同时保留了关键判断在人的手里。

该评审指南致谢自 PingCAP 社区的 Code Review Guide，可见这是一套被大型分布式数据库项目共同验证过的流程。延伸阅读：CONTRIBUTING.md（完整贡献流程与编码规范）、docs/design-docs/README.md（设计文档组织）、ci/jenkins/PR.groovy（PR CI 流水线）。