随着代码量的增多,服务模块的拆分,代码越来越难进行管理,质量与效率这一对矛盾体将凸显出来,就希望将代码质量管理的模式由原来人为主动控制转变成为由自动化工具检测,人被动接收通知,并且相关数据沉淀下来。Jenkins
大家都熟知是用来自动化单元测试、编译、打包及部署的,挺好用的。
基于另外一个出发点,针对代码规范,相信大家或多或少的了解过阿里巴巴开源的编码规范,看过就忘记了,在开发过程中,常常由于时间进度紧没能很好的执行,但程序真正运行起来出现问题往往都是这些潜在的问题与坏味道导致的,如果有一种工具能够将这些规则固化到日常开发流程中去,利用工具倒逼着自己提前考虑这些问题,那将大大的提高软件质量,也充当了一部分代码走读的功能,另一方面也能够将自己的知识结构更加系统化的锻炼,Sonar
就是为这个而生的,业界也提供了这两者的集成方式,方便的将流程集中在一起了,这也是持续集成中的部分概念。
本文档描述不清晰或者关于这两款工具软件其它功能的最佳实践,还望各位指正。
Jenkins
版本2.107.3
下载地址,我这里是下载的.war
包形式Sonar
版本7.1
下载地址,我这里下载的是Latest Release
版本JDK 1.8+
与Mysql 5.6+
这就不多说Maven 3.2.1
因为下载的是.war
包形式,也不存在其它的安装步骤,直接运行命令java -jar jenkins.war
即可将其跑起来,它将所有需要的资源文件都放在了这里,好方便,默认运行的端口是8080,多数情况下这个端口都会被占用,具体改法下面会讲到。大家可能都知道jenkins
是基于插件化的架构,所以安装完后,需要装一些基础的插件,像Maven Integration plugin
,Cobertura Plugin
,SonarQube Scanner for Jenkins
等等,如果公司的机器能够上网,安装这些插件都不是问题,本公司的网络环境有限,只有少部分机器能够上网,在这过程中遇到不少麻烦,因为如果将war
包转移到另外一台新的机器上时,它又是重新初始化,必须初步了解它的运行机制与目录结构,解决方法见下。
jenkins.war
包相当于它的运行主体程序,放在任意目录都可以/root/.jenkins
目录相当于它的运行时目录,包括配置、插件、工作空间、日志、节点、任务等重要信息目录,基本上看这个目录就够了,/root
是指用户目录,如果你使用的是alice
用户,那目录将变成/alice/.jenkins
程序运行起来后,浏览器访问http://IP:8080
进入初台化界面如下,首先会出现一个解锁的页面,按照提示的密码文件路径获取密码,将密码填入后下一步进入系统,进入后进行admin初始密码的修改。
成功进入主界面如下,具体相关的功能不再一一介绍,关于系统的配置功能均在系统管理
中。
离线安装一般有如下两种方式
执行命令java -jar jenkins.war --httpPort=8090
可对当前启动生效,但如果机器重启或将jenkins
做成系统服务怎么办,因为它本身没有提供配置文件修改,需要自己将端口写入环境变量,然后读取环境变量进行实现。
Sonar
是一个用于代码质量管理的开源平台,用于管理Java
源代码的质量。通过插件机制,它 可以集成不同的测试工具,代码分析工具,以及持续集成工具,比如checkstyle
、findbugs
、Jenkins
。通过不同的插件对这些结果进行再加工处理,通过量化的方式度量代码质量的变化,从而可以方便地对不同规模和种类的工程进行代码质量管理。同时它还对大量的持续集成工具提供了接口支持,可以很方便地在持续集成中使用它。此外,它的插件还可以对 Java
以外的其他编程语言提供支持,对国际化以及报告文档化也有良好的支持。可以说是目前最强大的代码质量管理工具之一。
它的主要作用如下:
SonarQube
通过插件Findbugs
、Checkstyle
等工具检测代码存在的缺陷SonarQube
可以展示项目中存在大量复制粘贴的代码Sonar
运行需要使用到数据库,它会将规则、用户、分析结果保存在数据库,需要执行以下语句进行数据库的初始化,其中的相关表是在程序启动初始化时创建的。
CREATE DATABASE sonar CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE USER 'sonar' IDENTIFIED BY 'sonar';
GRANT ALL ON sonar.* TO 'sonar'@'%' IDENTIFIED BY 'sonar';
FLUSH PRIVILEGES;
因为Sonar
在运行过程中使用了elasticsearch
数据库,但它不能使用root
用户启动,检查当前是否为root
用户,如果是则切换至sonar
用户。
将下载好的安装包sonarqube-7.1.zip
赋予sonar
用户权限,执行命令chown sonar:sonar sonarqube-7.1.zip
,然后解压。
解压后进入conf
配置目录,修改sonar.properties
文件,如下配置默认均是注释掉的。
sonar.jdbc.username=sonar
sonar.jdbc.password=sonar
sonar.jdbc.url=jdbc:mysql://localhost:3306/sonar?useUnicode=true&characterEncoding=utf8&rewriteBatchedStatements=true&useConfigs=maxPerformance&useSSL=false
进入bin
启动目录,该目录下根据操作系统与位数的不同而区分有不同的目录,这里选择的是linux-x86-64
,进入后执行命令./sonar.sh start
启动。
启动过程的相关日志存放在与bin
目录平级的logs
目录下。
Sonar
默认的语言是英文的,看起来不是那么方便,社区也提供了汉化版的插件下载地址
下载完成将插件放到\extensions\plugins
,重启sonar
即可。
sonar
高版本相比低版本发生了一个变化,以前低版本与外部接口使用用户名与密码,高版本则使用生成的token
,在初始化过程中会提示你输入一个用户名,然后生成token
,这个值就是以后与maven
及jenkins
集成时的接口凭证,当然也可以跳过,后面再生成。
浏览器访问http://IP:9000
进入主界面,如下图所示,具体相关功能不一一细讲。
自定义代码审查规则是根据每个公司的编码规范形成的,拿java
来说默认有许多,但不一定都需要满足,这个后续再研究。
在前面jenkins
中该装的插件都装了,接下来通过新建一个任务来实现,对svn
路径下的项目实现编译打包,代码规范检查,质量统计分析整个流程。
jenkins
与sonar
集成有两种方式,一种是在Post Steps
过程中使用SonarQube Scanner
分析,二是在构建后操作中使用SonarQube analysis with Maven
,相当于调用了maven
的插件与sonar
集成。这里使用的是第二种方式进行验证实现。
任务配置,任务配置如下所示,里面提供了很多过程阶段,像源码管理、构建触发器、构建环境、Pre Steps、Build、Post Steps、构建设置及构建后操作,这里我使用到了源码管理、构建触发器、Build与构建后操作四个过程
最后点击保存任务配置信息,你可以接下来就选择立即构建
功能来验证是否正确,或者等待你设置的周期定时器规则。
以上步骤实现从SVN
中拉取代码、编译、代码规范检查整个流程,我们将在jenkins
看到编译的结果,在sonar
中查看到代码质量的统计数据,问题一目了然的反映出来了。
maven
执行过程权限不够,错误如下,最终排查是由于我手动将maven
包传到linux
机器时,bin
目录下的启动脚本失去了可执行权限,赋权限即可[iotstp] $ /home/mzh/CI/apache-maven-3.2.1/bin/mvn -f /root/.jenkins/workspace/iotstp/pom.xml -e -B sonar:sonar -Dsonar.host.url=http://10.10.107.104:9000 ********
FATAL: command execution failed
java.io.IOException: error=13, 权限不够
maven
插件调用sonar
接口时找不到SVN
的用户名与密码,鉴权失败,解决措施为关闭掉sonar
中的scm
开关[ERROR] Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:3.4.0.905:sonar (default-cli) on project iotstp: Error when executing blame for file pom.xml: svn: E170001: Authentication required for ' VisualSVN Server' -> [Help 1]