4: 工程质量

ci 流程

• 日常 ci 流程

• 每次 push 或者 pull_request 代码之后自动执行 .github/workflows/ci.yml 里面定义的构建和测试步骤，！！！ci 失败不能进入 code review 流程。
• github/workflows/daily.yml 里面定义了每天要跑的回归测试，定时每天触发，里面需要加入长跑测试，回归失败需要走 bugfix 流程。

pr 规范

• 注意 pr 到 master 分支必须以 feature_[日期][功能英文缩写] 或者 bugfix[日期]_[功能英文缩写] 参考示例

feature_20230323_initciflow
bugfix_20230323_fixciflow

• 提交 pr 后必须至少一人 review 同意才能合代码

cr 规范

• cr 代码遇到疑问可以在 cr 里面评论出来，探讨最优解
• 必须 1 人以上 cr
• cr 前 ci 测试必须跑过

代码风格规范文档

• 严格遵从谷 C++ 风格规范，cr 时注意规范检查，或者 ide 安装规范检查的插件

https://zh-google-styleguide.readthedocs.io/en/latest/google-cpp-styleguide/contents/

• 禁止超长函数实现，多拆分
• 禁止荣誉实现，抽出公共函数
• 每个函数必须注释，能测试一定要写全单测

在项目目录下执行下面命令进行规范检查

find src -type f \( -name '*.h' -or -name '*.hpp' -or -name '*.cpp' -or -name '*.c' -or -name '*.cc' \) -print | xargs clang-format -style=file --sort-includes -i -n -Werror

自动格式化

find src -type f \( -name '*.h' -or -name '*.hpp' -or -name '*.cpp' -or -name '*.c' -or -name '*.cc' \) -print | xargs clang-format -style=file --sort-includes -i

单测规范设计

• 使用 gtest 测试框架
• 每个 gtest 测试文件按模块划分，例如存储层的测试 kvstorage_tests.cc，单测要尽可能多覆盖到函数执行的分支，命名要明确，例如

TEST(RaftTests, TestLeaderSyncFollowerLog2AB) {
 // add some test logical
}

集成测试规范

• 由于 eraftkv 是分布式系统，所以集成测试需要用 pytest 搭建分布式环境，之后压数据测试。
• 注意每个测试流程都需要覆盖到集群启动，运行测试，退出集群清理环境的流程。