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