CICD基本建成后,就可以按团队需要,加入合适的pipline或者旁通插件,一般情况下,都会加入Jenkins或者Travis等等,以达到基本的代码编译,测试,部署等环节,这些环节可能各个项目各有不同,本章节通过使用容器化SonarQube在pipline中加入代码质量扫描示例。

0x00 准备

启动一个sonarqube项目(容器服务),我这里使用sonarqube:8.4.2-community镜像,并且通过负载均衡或NodePort绑定容器9000端口
image.png
查看日志,出现Register rules就启动完成了,如果出现问题,请排查基础设施问题
image.png

0x01 配置

此处不赘述SonarQube的其他配置,例如语言配置,规则配置等,如果有其他需求,还需移步至其他社区地专门分享

** 访问绑定的host:port,登录SonarQube,默认账号admin/admin,进入[项目]菜单,创建项目,创建令牌,然后按照步骤下载质量检测的运行平台(这里实际上是脚本的执行平台)的脚本,然后对项目进行质量检测测试**

例如,在windows上下载sonar scanner后,会指引执行以下脚本:

sonar-scanner.bat -D"sonar.projectKey=code_quality" -D"sonar.sources=." -D"sonar.host.url=host:port" -D"sonar.login=1d0b030792a44c6190551dbde4119353b0ab1cc5"

执行完成后,命令行得到以下结果:

image.png

接下来就可以通过Web界面,查看技术债务:

image.png

0x02 集成

代码质量检测基础设施搭建完成后,就可以将其集成到目标项目的Pipline之中了

例如Gitlab,只需要配置好基础环境,并且添加Job即可:

job1:
  stage: test
  only:
    - master
  script:
    - sonar-scanner -Dsonar.branch.name=master -Dsonar.exclusions=$SONAR_EXCLUSIONS -Dsonar.projectKey=$CI_PROJECT_NAME -Dsonar.host.url=$SONAR_URL -Dsonar.login=$SONAR_LOGIN -Dsonar.sources=.  -Dsonar.java.binaries=. -Dsonar.java.source=8 -Dsonar.analysis.CI_COMMIT_REF_NAME=$CI_COMMIT_REF_NAME -Dsonar.analysis.GITLAB_USER_EMAIL=$GITLAB_USER_EMAIL -Dsonar.analysis.GITLAB_USER_NAME=$GITLAB_USER_NAME -Dsonar.analysis.CI_PROJECT_PATH=$CI_PROJECT_PATH

一般地持续集成工具,都能支持动态地对特定情况进行质量检测,例如通常我们只需要在开发分支合并到测试分支时,反馈给相关人员一篇全面的质量报告

0x03 总结

这个简单的示例,不仅运用了前面的基建设施,并且从长远来看,就质量检测这一个环节,从团队角度来看,就能省去大部分甚至全部的质量审查时间,并且也强制性和机械化的解决了长期积累技术债务和提供了风险屏障,从个人角度来看,能及时获得个人输出的评定,当然这需要团队成员共识和协作。