前言
随着团队规模的增大,由于每个人的开发风格,做事方式不尽相同,给项目的维护人员带来了极大的挑战。如何保证每个人遵循一致的coding style,commit messages conventions,merge request。。。如何让每个团队成员步调一致的、风格一致的参与到项目开发中来。
项目的开发过程中一些devops技术显得越来越有必要,一些开发规范化指导文档的书写也变得越来越有必要。此篇文章主要讨论如何在我们的项目中部署coding style,commit messages自动化规范化检查工具。
部署工具
我们可以在gitlab服务器上部署工具,或者在每个客户端部署工具。
服务端部署
我们采用Gitlab进行代码托管,在Gitlab上部署服务器有如下几个选择:
- 在服务器上部署git hook
- 使用gitlab的web hooks,在另一个服务器上部署工具,通过web hooks调用
- 使用gitlab的集成功能,譬如集成Jekins,在Jekins上部署工具,这需要在一台服务器上部署Jekins
综上在服务器上部署存在两个困难:
- 需要操作服务器的权限,甚至需要额外的服务器
- 部署工作量较大,时间成本,人力成本高
客户端部署
在客户端部署我们可以采用git hooks,但是git hooks都是存储在.git/hooks路径下的,没法提交,也就没法同步个每个拉取代码的开发者。有以下几个办法:
- 每个开发者自己下载hooks,部署到自己本地的每个仓库中
- 通过第三方工具husky
- 通过repo的hooks
上面几个办法的缺点:
- 不够自动化,太繁琐,容易出错,每个开发者拉取的每个仓库都需要操作一遍,而且如果hooks更新了,还需要手动同步
- 每个开发者需要安装配置husky,过程繁琐
- 项目需要使用repo进行管理
我们选择使用repo提供的hook,因为我们的SDK目前就是使用git-repo来进行多仓库管理的。它的实现也非常简单,由维护人员在git-repo仓库中创建hooks脚本。在每个开发者执行repo sync的时候,会自动同步git-repo仓库,包括其中的hooks脚本。被repo管理的多个仓库的hooks自动连接到git-repo的hooks。每个开发者无需关注这一过程,只需享受hooks带给他们的良好体验就可以了。
目前git-repo中部署了两个hook脚本:
- pre-commit 进行coding style检查(linux kernel coding style)
- post-commit 进行commit message检查(Git Commit Message 规范)
相关脚本暂存在 repo_hooks