CI/CD - 本地仓库CI流程

参考资料

CI/CD(Continuous integration;Continuous Deployment, 持续集成与持续部署)。这个过程连接了从代码编写完毕到交付测试环节的整个链路。如果能够将CI/CD做好的 话,研发人员只需要专注于业务实现即可(实际上不可能,开发很多时候得自己搭建环境测试)。

通过verifyCI 保证代码质量,代码提交会经历编译——运行测试用例——跑覆盖率、圈复杂度——各类自定义工具检测(中英文、模型包校验)等,从流程上减少出错的可能性。将这个过程自动化,大大提高了研发人员的开发效率。

代码规范工具

  • 代码格式化(VS code插件)和代码静态检测工具(cppcheck)

打造属于自己的本地CI流程

在git运行中的每个阶段,都暴露的生命周期的调用方法,通过增加相关的hooks文件我们可以非常简单的插入想要运行的shell命令。

git会自动扫描仓库git配置下hooks目录的文件,并去执行它。其中比较常用的有:pre-commit、commit-msg、pre-push 等钩子(hooks)。我们可以在 pre-commit 触发时进行代码格式验证,在 commit-msg 触发时对 commit 消息和提交用户进行验证,在 pre-push 触发时进行单元测试、e2e 测试等操作。

用于编写 git hooks 的脚本语言是没有限制的,可以用 nodejs、shell、python、ruby等脚本语言,非常的灵活方便。以 shell 语言为例演示一下如何编写 pre-commit 和 commit-msg 脚本。另外要注意的是,在执行这些脚本时,如果以非零的值退出程序,将会中断 git 的提交/推送流程。所以在 hooks 脚本中验证消息/代码不通过时,就可以用非零值进行退出,中断 git 流程。

pre-commit

在 pre-commit 钩子中要做的事情特别简单,只对要提交的代码格式进行检查,因此脚本代码比较少:

#!/bin/sh
npm run lint

# 获取上面脚本的退出码
exitCode="$?"
exit $exitCode
1
2
3
4
5
6

在项目中已经配置好了相关的 eslint 配置以及 npm 脚本,因此在 pre-commit 中执行相关的 lint 命令就可以了,并且判断一下是否正常退出。

// 在 package.json 文件中已配置好 lint 命令
"scripts": {
    "lint": "eslint --ext .js src/"
 },
1
2
3
4

commit-msg

在 commit-msg hooks 中,我们需要对 commit 消息和用户进行校验。

#!/bin/sh

# 用 `` 可以将命令的输出结果赋值给变量
# 获取当前提交的 commit msg
commit_msg=`cat $1`

# 获取用户 email
email=`git config user.email`
msg_re="^(feat|fix|docs|style|refactor|perf|test|workflow|build|ci|chore|release|workflow)(\(.+\))?: .{1,100}"

if [[ ! $commit_msg =~ $msg_re ]]
then
    echo "\n不合法的 commit 消息提交格式,请使用正确的格式:\
    \nfeat: add comments\
    \nfix: handle events on blur (close #28)\
    \n详情请查看 git commit 提交规范:https://github.com/woai3c/Front-end-articles/blob/master/git%20commit%20style.md"

    # 异常退出
    exit 1
fi
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

在 commit-msg 钩子触发时,对应的脚本会接收到一个参数,这个参数就是 commit 消息,通过 cat $1 获取,并赋值给 commit_msg 变量。