一. 简介
Sonar是一个用于代码质量管理的开放平台,相信大家都不会陌生。Sonar可以集成不同的测试工具,代码分析工具,以及持续集成工具。官方网站https://www.sonarqube.org
二. Sonar的三种用法
- 编写代码时做实时代码检查,有问题直接IDE里提示。参考https://www.sonarlint.org
- 提交代码自动触发检测+辅助code review。插件说明:https://gitlab.talanlabs.com/gabriel-allaigre/sonar-gitlab-plugin
- 定时全局代码检测
这三种方法分别发生在代码开发的3个时间阶段。很容易看到,第1种方式实际上是效率最高的。也推荐大家在自己的IDE里装上这个插件,将bug和不合规的代码扼杀在摇篮中。第3种用法则是一种事后的问题曝光,当发现时bug很可能已经进入master分支。如果没有前面2种用法,bug会持续不断的进入master分支,也缺乏对开发人员的有效提醒。
这篇文章主要说的是第二种方法
三. 为你的工程开启gitlab pipelines
1. 确保你有工程的master权限
2. 若看不见Settings/CICD这一栏,需要先打开Settings/General,确保Sharing and permissions 下的Pipelines不是disable的状态
3. 打开http://git.51.nb/你的工程地址/settings/ci_cd,并Enable sonar runner
4. 在工程根目录添加.gitlab-ci.yml文件(dev分支):
sonar:
stage: test
script:
- ~/sonar.sh
tags:
- sonar
四. 使用场景
场景1:提交代码自动扫描(注意,只扫描更改的文件),邮件通知作者本次提交有bug需要改
点击链接查看,sonar会自动在代码里加comment:
最下方展示该提交文件其他bug:
Sonar自动给你的gitlab添加todos:
场景2:merge request,code review,若存在bug,审核者可选择不予通过
场景3:每次扫描全部代码
.gitlab-ci.yml文件内容:
sonar:
stage: test
script:
- ~/sonar.sh -a
tags:
- sonar
场景4:特定分支扫描
.gitlab-ci.yml文件内容:
sonar:
stage: test
script:
- ~/sonar.sh
tags:
- sonar
only: - master - release - dev
场景5:查看问题+定制化
在gitlab上系统的查看问题还是比较麻烦,我们可以进入http://10.247.22.137:9000/projects 查看问题。注意,这个是为gitlab提交自动扫描专门搭建的最新版的sonar,不同于公司现在用的sonar.51.nb:9000。如果觉得问题检测对于自己的代码块是误报,在经过直属上级的评估后可以将此规则基于该项目降级。
五. 要求
- 对于p0,p1的java应用,强烈建议开启以上代码检测!
- 其他级别的应用视情况开启即可
六. 后续计划
- 任务由单机改为docker化,提升性能。
- 和ares平台打通
结语
相信阅读本文的各位开发同学都不想仅限于代码的搬运工,Sonar就像是个代码经验极其丰富的老师,他会任劳任怨的帮助我们完善自己代码,让我们的code变得更健壮、更规范、更优雅。虽然有时候某些issue看上去不是什么大问题,但即使只是防御代码,也会有它的价值所在。希望大家都能成为有“代码洁癖”的程序猿