技术管理者---提升研发代码质量---代码检查工具Sonar

本文是《技术管理者---提升研发代码质量》系列文章第二篇,第一篇整体介绍请看博文《技术管理者---提升研发代码质量---总体方法论》。本文重点讲三部分内容:1)sonar是什么,研发体系如何利用sonar提供代码质量;2)开发过程中如何使用Sonar保证代码质量;3)sonar与Jenkins持续集成,持续闭环研发代码质量。

Sonar是什么?能干什么?

Sonar是一个用于代码质量管理的开源平台,用于管理源代码的质量 通过插件形式,可以支持包括java,C#,C/C++等多种编程语言的代码质量管理与检测。Sonar可以从以下7个维度检测代码质量:

  • 不遵循代码标准:包含CheckStyle,Findbugs等等代码规则检测工具
  • 潜在的缺陷:包含CheckStyle,Findbugs等等代码规则检测工具
  • 糟糕的复杂度分布:检查过高复杂度的文件、类、方法
  • 重复:重复代码检查
  • 注释不足或者过多:
  • 缺乏单元测试:
  • 糟糕的设计:找出包与包、类与类之间相互依赖关系

先放几个Sonar能发现的问题常见问题代码截图:

能够发现Sonar检测出很多研发质量不规范、非常容易出错的地方,作为研发管理者你肯定会想:这么好的工具,我们研发团队一定要使用起来。 这种想法非常好,但一个更关键的问题是:研发团队如何使用Sonar,如何和现有研发流程规范结合起来,这就需要将Sonar检测结果作为现有研发流程中的重要一环,才能让Sonar长期发挥作用。 不然只会出现如下的情况:研发经理说下个版本开始我们使用Sonar检测代码啊,只有检测通过了才行。 相信我,过2个月之后,你将发现没人按照你说的去执行。

要想让Sonar与现有研发流程紧密结合、提升研发质量,我们先来了解一下Sonar家族体系。

然后再来看看Sonar报告发现问题的种类

最后来看作为技术管理者,如何将Sonar作用在研发流程与持续集成环境当中

PS:上面讲解的研发流程维度使用Sonar的方式需要人的参与,不是最好的方案,最好的方案是开发人员在提交代码到Git的时候,自动触发Sonar增量检测,并能将错误信息返回到Git提交客户端,这种方案需要修改Git客户端与服务器端逻辑,代价太大了。目前业界有一种Sonar+Gerrit配合使用,能够达到上面的效果,只是使用Gerrit的代价也较大,需要同步Gerrit与GitLab的仓库、同步账号、同步权限等一系列的同步,非常容易因为同步不成功而导致整个代码提交、打包产生问题。故博主所在公司使用上图中的方案。

下面讲解如上研发体系使用Sonar做静态代码检测的两种整合方案,详细的实施方案。

开发过程中如何使用Sonar保证代码质量

Idea开发中安装Sonar插件《SonarLint-3.4.0.2532.zip》,菜单路径“Idea-->File-->Setting-->Plugins-->Install plugin from disk”,截图如下

安装完成之后,重启Idea,就能看到当前打开文件的检查报告结果,如下:

点击右侧Report,可以检查整个工程Sonar扫描结果

这样每位开发同学在提交代码前都会将本次任务里涉及到的代码做Sonar静态检查,检查通过后截图到自测报告中,完成的规范与研发流程强关联。

Sonar与Jenkins持续集成,持续闭环研发代码质量(安装Jenkins、SonarQube,并整合服务每天出自检报告)

安装Jenkins,网络上有很多安装Jenkins的完整文章,读者可以直接参照,本博文里面就不详细介绍了,可以参考:《https://blog.csdn.net/sms15732621690/article/details/71336224》

安装SonarQube服务,网络上也有很多完成的文章,读者可以直接参照,本博文里面就不详细介绍了,可以参考:《https://www.cnblogs.com/ding2016/p/8065241.html》。

这里面有几个坑特别要注意:

  • 要想运行SonarQube,操作系统至少要有2G空闲内存,不然服务可能会无缘无故的进程没有,特征如下:
2018.09.06 17:11:31 INFO  app[][o.s.a.SchedulerImpl] Process[ce] is up
2018.09.06 17:11:31 INFO  app[][o.s.a.SchedulerImpl] SonarQube is up
2018.09.06 17:26:39 WARN  app[][o.s.a.p.AbstractProcessMonitor] Process exited with exit value [es]: 137
2018.09.06 17:26:39 INFO  app[][o.s.a.SchedulerImpl] Process [es] is stopped
  • 启动好SonarQube的时候,切记把token记录下来,后面在和Jenkins整合的时候需要。

下面介绍Jenkins与SonarQube的整合方式,根据官方文档《https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner+for+Jenkins#AnalyzingwithSonarQubeScannerforJenkins-AnalyzingwiththeSonarQubeScanner》介绍,整合方式4种方式。 博主所在企业实用第一种“Analyzing with the SonarQube Scanner”,大部分的互联网企业,应该是采用第三种” Analyzing with SonarQube Scanner for Maven or Gradle”。下面详细介绍第一种整合方式详细配置过程(也可以先看官方文档做了解)。

  • 配置Jenkins系统管理--->插件管理--->安装”SonarQube Scanner for Jenkins”(如下),安装成功后重启Jenkins

  • 配置Jenkins系统管理--->系统设置--->配置” SonarQube servers”(如下),注意这里需要应用前面安装SonarQube的Token。 其他的配置正常进行(Java、Git等)

  • 新建“构建一个自由风格的软件项目”任务,分别配置好“GitHub”、”源码管理”、”构建触发器”,”构建环境”,”构建类型Execute SonarQube Scanner”分别截图如下:

 

上面的sonar.sources用于设置项目的源码地址,一般实际项目上,源码都是在很多子工程的,所以这里需要写多个,多个源码地址用,号隔开,路径可以使用相对路径。

  • 配置完成后点击”立刻构建”构建成功后即可看到结果,可在Jenkins中快速链接到SonarQube中的结果。截图如下:

 

至此,大功告成,让此静态检查持续集成方法,提升你们团队的 代码质量吧。

猜你喜欢

转载自blog.csdn.net/chengyun19830206/article/details/82874439