基于gitlab ci_cd实现代码质量管理

在日常的代码开发工作中，为了管理代码的质量，不管是开发团队，还是测试团队，或多或少都有一些自己的管理规范。 但是规范的执行需要强有力的工具，本文将使用 Gitlab CI/CD + Sonarqube 的方案，把代码质量管控进行工具化、流程化，纳入到日常的开发工作中。

整体架构

流程说明： 开发人员发起代码的 push 或者 gitab merge request 时，会触发 gitlab 运行 ci/cd 流水线作业任务，根据代码质量的检测结果（或其他规范条件），来确定是否允许合并到特定分支。

依赖的服务工具： gitlab ci + gitlab runner + sonarqube + sonar notify + 钉钉。 具体的作用说明：

0. gitlab-ci： 所有 ci 动作的入口，用于调度具体的 ci 任务。
1. gitlab-runner：真正执行代码分析的服务器。
2. sonarqube：提供代码检测的规则配置和结果展示等。
3. sonar notify：自研的小工具，处理 sonarqube 报告结果，并且文字高亮排版，发送到钉钉群等渠道，并@项目负责人。也可以使用 sonarqube 的钉钉机器人插件来替代。

操作步骤

主要分为以下几个部分：

0. gitlab 设置 CI 环境
1. sonarqube 环境设置
2. 项目设置

1. gitlab 设置 CI 环境

该部分的操作，均在 gitlab 的具体代码仓库中进行，仅针对具体项目，不涉及到全局操作，需要项目的 Manitainer 角色权限。

1.1 gitlab 启用 ci

一般新建的项目仓库中，会自动开启 gitlab 的 ci 功能，若项目代码仓库中看不到 ci/cd 的配置入口，在以下设置路径中开启：

Settings -> General -> Visibility, project features, permissions -> CI/CD -> 切换开关启用 CI/CD -> Save Changes 保存即可

1.2 项目关联 gitlab runner

在启用 gitlab ci 之后，在以下设置中配置 gitlab runner：

Settings -> CI/CD -> Runners

模式选择 在 runners 设置页中，有三种模式的 runner 可以设置：

0. Specific runners：指定具体的 runner 服务，有自动配置和手动配置两种方式。手动配置的话，每个项目都有 registration token，可以在 runner 服务器中，添加该项目 token，然后该项目即可使用该 runner 服务器进行代码分析。
1. Shared runners：共享的 runner，所有的项目均可使用的 runner，受限于资源问题，所有项目均使用共同的 runner，会导致排队拥堵。
2. Group runners：项目组下的 runner，该 runner 是作用于 gitlab 某个 group 下的，该 group 下的项目均可以使用该 runner 服务。如果 group 管理规范，也可以使用这个模式。

当前使用的是第一种 Specific runners，灵活度较高，因为暂时没有用于 CI/CD 自动化的 Kubernetes 集群，采用手动添加的方式。在 Set up a specific runner manually 说明中，按应用的 token，关联具体的 runner。

⚠️ 如果没有 gitlab runner 服务，需要一台服务器资源，安装 gitlab runner 服务。在 "Show Runner Installation instructions" 说明中，针对不同的环境，有详细的安装步骤。 若企业内有统一可用的 kubernetes 集群，推荐基于该方式安装 runner，可以更好的管理 runner 资源。

关联操作 具体关联操作是在已安装 gitlab runner 的服务器中，以管理员身份执行该命令：

sudo gitlab-runner register --url $YOUR_GIT_REPO[替换成项目的git地址]  \
 --registration-token  $REGISTRATION_TOKEN[替换成项目的 registration token]

执行该命令后，会让输入一些注册信息，其中有两项是要特殊注意的，一个是 tags 设置，本方案 ci 规则统一设置为 merchant-ci，一个是 ci 脚本的执行类型，按需选择，本方案使用的是 shell。

-> Enter tags for the runner (comma-separated): -> merchant-ci -> Enter an executor: docker-ssh, shell, ssh, docker+machine, kubernetes, custom, docker, parallels, virtualbox, docker-ssh+machine: -> shell

操作完成后，刷新 gitlab 的 CI/CD 设置页面，可以看到具体的 runner 服务。

2. sonarqube 环境设置

以实际的 sonarqube host 服务地址为准。 如果项目已经在 sonarqube 中新建过，无需新建。 如果项目没有在 sonarqube 中设置过，需要新建项目，并且进行初次的分析。

2.1 新建项目

新建项目表单中，填写项目标识和显示名。

2.2 初次分析

创建令牌，并且进行分析。按 sonarqube 中提供的命令即可。如果是后端 java 语言项目，需要 mvn 或者 gradle 等构建工具。

2.3 项目质量域设置

在具体项目的 "项目配置 -> 质量域" 中，按团队规范，对新代码和全量代码设置违规条件规则。 以笔者所在团队的规则为例，由于历史项目较多，当前未对历史代码做严格控制，仅对新代码进行违规控制，违规条件如下：

指标	操作	值
覆盖率	小于	50%
Bugs	大于	0
阻断违规	大于	0
严重违规	大于	0

2.4 检测结果报告

sonarqube 是通过网络调用 webhook 的方式，将结果通知到具体的地址。可以全局设置/单项目设置，推荐全局设置，设置路径如下：

配置 -> 配置 -> 网络调用

我们团队自研了 SonarNotify 服务，用于处理 webhook post 的结果。也可以使用 sonarqube 钉钉插件替代。

3. 项目设置

3.1 增加 gitlab ci 文件

项目代码的根目录中增加 CI 配置文件，文件名：.gitlab-ci.yml，内容如下：

variables:
  APP_NAME: "xxx-project"
include:
  - project: 'zcy/ci'
    file: '/.gitlab-ci-template.yml'

说明：

0. APP_NAME 按照实际的项目名字为准，要与 sonarqube 中配置的项目名字一致。
1. include 中的内容是指引用其他 project 下的公共 file，比如上面的含义是：引用 gitlab 仓库中 zcy/ci 这个工程里面的 .gitlab-ci-template.yml。 一般是将 gitlab 的 ci 配置文件统一维护起来，放到某个 git 工程项目里面，其他服务直接 include 引用。

gitlab 的 ci 配置文件是最核心的部分，这里配置着流水线作业的编排和作业的触发规则。其中的流水线、作业、变量的详细语法信息，参考： 官方 gitlab ci/cd 文档

本方案的一个简单的案例：

⚠️ job 的 tags 要与 gitlab-runner 里面关联的 tag 保持一致 该 job 的触发规则 rules 含义： 除了 合并到test/test分支的MR，或者已经存在MR的push操作，其他的情况均触发该job

3.2 设置覆盖率插件

该操作是针对后端 java 项目，在项目的根 pom.xml 中，增加插件，内容如下：

3.3 排除和忽略处理

并不是所有模块、包或者文件需要进行代码的扫描和覆盖率计算的，可以采用以下方式进行排除忽略处理。

(1) 排除一个 module 在需要排除的模块中，在其 pom.xml 的 properties 属性中，增加 sonar.skip 配置：

<properties>
    ...
    <sonar.skip>true</sonar.skip>
</properties>

(2) 排除包或者文件 某些文件，比如 model dto 对象，或者单测的代码，不需要进行代码质量检测，也不需要对这些代码进行单元测试，可以在对应的 pom.xml 的 properties 属性中增加忽略配置:

<properties>
    ...
    <!-- 在源代码 (src/main) 目录下排除代码质量扫描 -->
    <sonar.exclusions>
      **/*Model.java
    </sonar.exclusions>
​
    <!-- 在测试代码 (src/test) 目录下排除代码质量扫描 -->
    <sonar.test.exclusions>
      src/test/**/*
    </sonar.test.exclusions>
​
    <!-- 排除单测覆盖率 -->
    <sonar.coverage.exclusions>
        **/domain/**/*,
        **/pojos/*
    </sonar.coverage.exclusions>
</properties>

结果预览

1. 钉钉结果通知

2. Sonar 分析详情

在 sonar 平台中查看对应的项目即可。

3. gitlab MR卡点

代码质量检测不通过，无法进行MR合并：

扩展

0. 因为 gitlab ci/cd 中流水线可以组合多种作业任务，并且作业的规则是可以自定义的，我们可以在此做各种前置的其他校验处理，比如在某个老东家的项目中，检测当前应用的 API 版本是否符合公司的要求。 因为规则可自定义，任何条件检测，只要脑洞够大，都可以在该阶段中进行。
1. 本文未涉及到 cd 的部署流程，如果企业的运维团队，提供部署的 API 能力，也可以通过流水线规则，触发自动的部署。

总结

基于以上的配置，将质量的管控融入开发工作流，可以强有力的保证代码的质量检测和规范执行情况，提升整体的研发质量。

参考资料

0. [gitlab ci/cd 与 Kubernetes 结合使用] docs.gitlab.cn/jh/user/clu…
1. [sonarqube webhook] docs.sonarqube.org/latest/proj…
2. [gitlab ci/cd 官方文档] docs.gitlab.cn/jh/ci/

推荐阅读

sharding-jdbc 分享

用户路径分析

浅析 MySQL 中 join 查询

为什么 Redis 这么快之数据结构

从源码看 Lucene 的文档写入流程

招贤纳士

政采云技术团队（Zero），一个富有激情、创造力和执行力的团队，Base 在风景如画的杭州。团队现有 500 多名研发小伙伴，既有来自阿里、华为、网易的“老”兵，也有来自浙大、中科大、杭电等校的新人。团队在日常业务开发之外，还分别在云原生、区块链、人工智能、低代码平台、中间件、大数据、物料体系、工程平台、性能体验、可视化等领域进行技术探索和实践，推动并落地了一系列的内部技术产品，持续探索技术的新边界。此外，团队还纷纷投身社区建设，目前已经是 google flutter、scikit-learn、Apache Dubbo、Apache Rocketmq、Apache Pulsar、CNCF Dapr、Apache DolphinScheduler、alibaba Seata 等众多优秀开源社区的贡献者。如果你想改变一直被事折腾，希望开始折腾事；如果你想改变一直被告诫需要多些想法，却无从破局；如果你想改变你有能力去做成那个结果，却不需要你；如果你想改变你想做成的事需要一个团队去支撑，但没你带人的位置；如果你想改变本来悟性不错，但总是有那一层窗户纸的模糊……如果你相信相信的力量，相信平凡人能成就非凡事，相信能遇到更好的自己。如果你希望参与到随着业务腾飞的过程，亲手推动一个有着深入的业务理解、完善的技术体系、技术创造价值、影响力外溢的技术团队的成长过程，我觉得我们该聊聊。任何时间，等着你写点什么，发给 zcy-tc@cai-inc.com

微信公众号

文章同步发布，政采云技术团队公众号，欢迎关注