[DevOps自动化-10] 招唤SonarQube

SonarQube是程序扫描的神兵利器,可针对每次PR的差异做扫描,让大家只需对自己的程序负责,当每人都对自己负责时,团队的程序品质就会呈现良好的向上循环。


前言

程序扫描工具种类繁多,但SonarQube有一个惊为天人的功能,就是能针对每次PR的差异来做扫描,现今大部分团队,除了新创公司,大部分都有沉重的包袱,所以传统项目随便扫都成千上万的待处理事项,让开发人员还没开始修改就先举白旗投降了。但如果是针对每次PR的差异来做扫描,那状况就完全不一样了,自己的坑自己填,天公地道,当大家都对自己的程序负责时,整个团队就会对坏味道的程序产生厌恶感,进而让项目的品质呈现正向的向上循环,话不多说,就赶快试试SonarQube来帮助团队解脱吧。

架设SonarQube?Server

由于SonarQube需要Java的环境,因此,需要先安装Java,Java下载的网址,Windows直接执行安装档即可,打开PowerShell,输入Java出现下图画面代表安装完成。

分享图片

SonarQube还需要一个数据库保存分析结果,因此,需要建立一个SQL Database,当然它不仅只支持MSSQL,但本文范例用MSSQL来实践。新增一个数据库,名称输入SonarQube。

分享图片

接着调整定序,然后按下OK,数据库建立完成。

分享图片

Java环境安装完成,并且建好数据库之后,接下来去SonarQube官网下载项目。

分享图片

下载来的文件是一个zip档,直接解压缩,放到自己喜欢的路径,我是直接放在C:底下。接着在sonarQube数据夹下的conf数据夹会找到sonar.properties,点选开启,按照下面步骤的格式填写SQL的连线资讯。

分享图片

接下来移动到sonarqube的bin数据夹,根据主机的windows版本,下图范例是64位版本,执行StartSonar.bat,最后如果出现Process is Up代表启动成功。

分享图片

在工作管理员的地方确认服务是否有正常跑起来。

分享图片

都没有问题的话,直接在浏览器上输入localhost:9000,就会开启下列画面,代表服务架设完成。

分享图片

如果想修改PortNumber 也是在Sonarqube的Conf的sonar.properties文件做修改

?

整合SonarQube到VSTS的Build Step

总共有两个步骤需要实践,首先,跟Jenkins一样需要建立Servcie的End point,接下来将SonarQube的Plugin整合到Build Step内。

设定SonarQube的Service

SonarQube没有专属的Endpoint类型,所以,请选择Generic类型。

分享图片

Connection Name是自订名称,取一个喜欢的名字就可以,Server URL是刚刚安装完SonarQube可开启网页的URL,帐密如果没更改的话,默认是admin/admin,然后按下OK就建立完成。

分享图片

整合SonarQube到Build Step

接下来的动作就是要将SonarQube整合到Build?Step内,由于有plugin的协助,剩下的动作非常容易,打开Build Step新增两个Step,如下图所示。

分享图片

接着移动位置,要像夹心饼干一样,把你Build的步骤包起来。

分享图片

接下来设定Begin Analysis的步骤,如果上一个步骤SonarQube的Service Endpoint设定正确,在1号球处就可以直接选到,2号球处的Project Key和Project Name可以自订,取一个喜欢的名字即可,最后按下Save存档。

分享图片

设定完成就直接来Run一个看看,一样回到Build的页面,按下Queue a new build,便会开始执行,由下图可以看到执行成功,SonarQube已经整合到Build Step内了。

分享图片

SonarQube展示报表

登入到SonarQube的页面,可以看到刚刚扫描的结果已经出来了,在上个步骤有填入Project Name是DemoSonarQube,所以可以看到下面的扫描结果有一个叫做DemoSonarQube的项目。

分享图片

直接点选连结可以看到项目的健康状态报表,恩,看起来非常健康,迷之声:因为根本是空项目吧。

分享图片

让SonarQube自动将建议填写在PR的注解区

设定develop branch的Policy,并选择我们刚刚建立好的Build定义,并且勾选Always require a new build。

分享图片

设定好之后,只要PR要求合并到develop,便会自动触发build,等SonarQube扫描完毕,Code Reviewer可以直接在PR的地方看到SonarQube的建议,如下图所示,我们可以发现两个变量的命名都有相同的问题,但SonarQube只要标注第二个变量AA002s有问题,却未标注AA001s,是因为AA001s是原本的Code,而这次的变更只有AA002s,所以,别再找借口怪前人挖坑,你有权利不填别人的坑,但请别跟着一起挖,自己对自己的程序负责,非常的公平!!!

分享图片

SonarQube所定义的规则,不一定全部都符合团队需求,所以规则可以调整,调整出适合自己团队的规范,然后大家约定一起遵守。

总结

从首篇文章开始,我们走过了透过msbuild将项目封装成package,并且再透过msdeploy将项目发布到站点,然后进化成,透过Jenkins一键完成前面的动作,然后再进化为VSTS合并分支之后,触发Jenkins完成前面的任务,接着建立了VSTS的Build Step当我们的守护神,每次PR后会自动编译、跑测试,最后导入程序扫描,为程序品质做更进一步的把关。

整个DevOps的雏型已经完成,接下来就是要再针对团队的需求再去做更细部的设定调整,但项目产品已经有最基本的保障,随着测试覆盖率的不断增长,想改坏系统终于会变得愈来愈不可能了。呼~好累,最近感觉东西记不太住,走过的路,如果不赶快记录下来会觉得很不踏实,写到这里,终于可以放松一下了....

原文:大专栏  [DevOps自动化-10] 招唤SonarQube

相关文章
相关标签/搜索