Jenkins学习:第五,部署配置Sonar(一)

By | 2017-03-14

通过上面四个章节的学习,jenkins的基本使用已经可以了,对于Jenkins来说,我们完成了代码的checkout、compile、package相关功能,对于基础的使用已经可以了,但是如果对代码质量有要求呢?

这一节我们开始学习Sonarqube与jenkins结合使用。

1、下载

官网地址:

https://www.sonarqube.org/

下载网址:

https://www.sonarqube.org/downloads/

最新下载:

https://sonarsource.bintray.com/Distribution/sonarqube/sonarqube-6.2.zip

网站显示最新版本是6.2,稳定版本是5.6,但经过测试,5.6版本会有数据库版本兼容问题,会报启动web应用失败,因此建议采用6.2版本,不用为了这个升级改变数据库。

2、配置

下载好的zip包解压一下,然后改一下文件夹名称为sonarqube,进入文件夹,找到conf目录下的文件。

2.1、sonar.properties配置

创建数据库sonar,网上教程一般推荐单独创建数据库用户sonar,你也可以这样做。

配置数据库信息,我这里用的是mysql数据库:

sonar.jdbc.username=sonar

sonar.jdbc.password=sonar

sonar.jdbc.url=jdbc:mysql://121.40.133.100:3306/sonar?useUnicode=true&characterEncoding=utf8&rewriteBatchedStatements=true&useConfigs=maxPerformance

sonar的默认端口是9000,你也可以根据自己的喜欢进行调整,我们这里用默认的。有很多教程还关注到了其他的参数配置,这里可以略过,当你需要的时候再来细看、调整。

2.2、wrapper.conf配置

网上很多教程忘了这个配置文件,这样会导致wrapper执行的时候报错,直接启动不了,这个地方也只需要改一个配置:

wrapper.java.command的默认值是java,需要修改成你的JAVA_HOME目录后面加上/bin/java,比如:

wrapper.java.command=/usr/local/jdk1.8.0_101/bin/java

3、启动

配置完成之后就可以进入启动步骤了,在sonar的根目录的bin目录下,对应不同的系统有不同的启动方式,比如我们的系统用bin/linux-x86-64/sonar.sh start/stop/restart来进行操作。

如果你是远程访问,记得打开防火墙的对应端口,否则会访问不到。系统的默认帐号密码是admin/admin。

另外,启动的时间和过程会比较漫长,因为这个过程sonar会链接数据库,创建并初始化几十个表及数据,这时候你可以用ps -ef | grep sonar看一下centos下的sonar进程是否在,同时可以通过less logs/sonar.log查看对应的启动日志,出错了也知道,不用干等。

 

4、插件安装

进入sonar的DashBoard之后,sonar的默认界面是英文界面,因此我们可以通过插件的方式进行安装对应汉化插件,网上有说下载对应的plugin包放到对应目录,比较麻烦,不采用。

通过顶部菜单Administrator进入设置页面,然后在中部菜单找到System(系统),选择后会出现下拉菜单,选择Update Center(更新中心),即可进入到插件对应页面。

插件页面首先展示的是Installed页面,我们要操作Avilable,然后通过搜索Chinese获得我们要安装的Chinese Pack,Install即可,这个过程需要等待服务器响应。

在等待响应的过程中,我们可以将java的相关插件一并安装了,搜索java会出现几个插件:Java、Findbugs 、Checkstyle、sonarJS等。

等所有的插件都安装完成之后,可以通过界面进行重启sonar服务,也可以通过后台命令去重启服务,我选择后者,比较快速,当然重启还是需要等待的。

5、项目管理

重启之后,我们进入DashBoard界面之后选择顶部菜单配置(Administartor),然后选择项目,出现下拉菜单中选择management即进入项目管理中,这个菜单只有管理员有权限进行配置项目。

选择create project会弹出对应的创建项目页面,主要是项目的名称和项目的标识即Name和Key,Branch是可选的,没有深入去看。

这里配置的name和key会在与jenkins协同进行代码审查的时候会用到,每个项目和key要一一对应,配置完成点击create就可以了,该项目会出现在DashBoard的所有项目那一列中。

Tips:这一节只是简单安装和配置sonar这个服务,下一节说说jenkins的sonar配置、sonar-runner配置及对应项目的配置。

Jenkins学习:第四,环境配置

By | 2017-03-13

今天简单说是环境变量的配置,涉及到jenkins使用到的一系列软件、插件,包括maven、JDK等

1、maven

1.1、下载

下载网址:http://maven.apache.org/download.cgi

linux下载:http://apache.fayea.com/maven/maven-3/3.3.9/binaries/apache-maven-3.3.9-bin.tar.gz

windows下载:http://apache.fayea.com/maven/maven-3/3.3.9/binaries/apache-maven-3.3.9-bin.zip

 

1.2、环境变量

解压对应下载包,然后配置环境变量M2_HOME是maven的根目录

将$M2_HOME\bin加入到PATH变量中即可

1.3、测试

打开命令行工具,输入mvn -v获取maven的版本信息

2、JDK

2.1、下载

这里的JDK版本用的是oracle的版本。

下载网址:https://jdk8.java.net/download.html

Linux下载:http://www.java.net/download/java/jdk8u152/archive/b01/binaries/jdk-8u152-ea-bin-b01-windows-x64-10_feb_2017.exe

windows下载:http://www.java.net/download/java/jdk8u152/archive/b01/binaries/jdk-8u152-ea-bin-b01-linux-x64-10_feb_2017.tar.gz

2.2、环境变量

解压对应下载包,然后配置环境变量JAVA_HOME是JDK的根目录

将$JAVA_HOME\bin加入到PATH变量中即可

2.3、测试

打开命令行工具,输入java -version获取JDK的版本信息

3、Jenkins配置

上面两点都是基础的软件安装,Jenkins要使用起来还是需要一些配置的。

进入Jenkins的Dashboard之后,在左侧可以看到系统管理,点击之后进入二级页面,找到Global Tool Configuration ,这是配置全局工具的地方,我们的主要工作是调整这些内容。

3.1、Maven Configuration

软件maven的配置文件,这个可以不改,但是对于国内maven用户来说,maven会出现下载超时失败等状况,因此需要通过修改maven的默认镜像来解决这个问题,比如阿里云的maven镜像。

a、找到maven的安装目录下的conf目录下的setting.xml文件

b、找到mirrors标签,在标签下方增加如下代码即可:

​<mirror>
​    ​<id>alimaven</id>
​    ​<name>aliyun maven</name>
​    ​<url>http://maven.aliyun.com/nexus/content/groups/public/</url>
​    ​<mirrorOf>central</mirrorOf>
​</mirror>

3.2、JDK

​JDK的安装就是设置JDK的别名,比如JDK8标识当前版本,然后在JAVA_HOME对应的项填入上面的JDK安装路径的根目录即可

3.3、Git

​    ​Git的安装需要去网上找对应教程或者根据官方文档安装,设置类似JDK添加别名和对应路径或者执行方法

​我们的Jenkins的系统环境是CentOs,系统的git版本是1.7,所以我的参数是git1.7,Path to Git executable的值是git,这样就可以了。

​Windows下需要安装并配置对应路径即可。

3.4、Maven

​Maven的配置就是设置maven的别名及对应MAVEN_HOME的值,我们这里别名设置的是maven3.9,MAVEN_HOME是maven安装的对应根目录即可。

 

Tips:这里只是简单交代了初始化安装完成之后的配置,我们接下来要进行的代码质量分析、代码审查用到的Sonar和sonar Runner还需要再次进行配置,敬请期待咯~

Jenkins学习:第三,maven构建的项目配置-pom.xml文件

By | 2017-03-11

对于maven项目,原来构建的时候,连本机的maven环境变量都没有用起来,IDE中maven的状态一直是个摆设,着要用Jenkins肯定不行了,构建一下就各种错误,甚至直接执行不了,看了错误会抓狂,各种文件找不到是个很大的问题。于是觉得应该好好学一下关于maven的构建配置。

在学习的过程中,主要参考一片博客:http://blog.csdn.net/tomato__/article/details/13625497 ,备用链接:http://www.icnws.com/?p=279

根据博客的内容,自己摸索了一个基本的配置方法,刚开始总是编译出错,目录不对,war包文件内容也不对。

1、配置maven环境变量

简单,解压对应tar/zip包,然后配置环境变量M2_HOME,并将环境变量即${M2_HOME}加入系统的PATH变量中。windows系统按照配置环境变量的方式,linux配置更新/etc/profile或者.bash_profile

配置完成之后,需要用mvn -v 测试一下,如果能看到版本信息就可以了,否则就可能是配置失败

2、配置IDE使用maven

我们开发一般用Android studio、eclipse、IDEA,找到maven配置的地方,选择你安装maven的根目录即可

3、配置pom.xml文件

pom.xml配置文件很重要,之前主要是通过maven添加依赖,至于build相关的内容基本上没有怎么用,所以几尽周折才搞定。

<groupId>com.icnws</groupId>
<artifactId>icnws-tx</artifactId>
<packaging>war</packaging>
<version>1.1</version>

<build>
    <finalName>icnws-tx</finalName>
    <defaultGoal>package</defaultGoal>
    <directory>${basedir}/target</directory>
    <resources>
        <resource>
            <targetPath>${basedir}/target/icnws-tx/WEB-INF/classes</targetPath>
            <directory>${basedir}/src/main/resources</directory>
            <filtering>false</filtering>
        </resource>
        <resource>
            <targetPath>${basedir}/target/icnws-tx/</targetPath>
            <directory>${basedir}/web</directory>
            <filtering>false</filtering>
        </resource>
    </resources>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-war-plugin</artifactId>
            <version>3.0.0</version>
        </plugin>
    </plugins>
</build>

 

一点点来,首先是项目的maven配置

<groupId>com.icnws</groupId>
<artifactId>icnws-tx</artifactId>
<packaging>war</packaging>
<version>1.1</version>

这里主要关注packaging,我们的目标是生成war包文件,也由生成jar包的,跟需求来,其他就不用说了

接下来是build相关的参数配置
finalName是build之后发布的项目、生成的包名,这里就是icnws-tx.war和项目目录icnws-tx
defaultGoal是build的目标,我这里写的是package,就是打包,也可以install等参数
directory是build之后放到哪里,${basedir}是指项目的根目录,target是指放到项目根目录的target文件夹下,编译的Java class文件都会放到这个文件夹之内

接下来就是一些不需要编译的配置文件,resources,由于我们的项目结构是:

${basedir}/

–src/java/main

–src/java/resource

–lib

–web

这种结构,所以我需要配置两个resource标签,将相关目录下的文件放到打包目录,如下:

    <resources>
        <resource>
            <targetPath>${basedir}/target/icnws-tx/WEB-INF/classes</targetPath>
            <directory>${basedir}/src/main/resources</directory>
            <filtering>false</filtering>
        </resource>
        <resource>
            <targetPath>${basedir}/target/icnws-tx/</targetPath>
            <directory>${basedir}/web</directory>
            <filtering>false</filtering>
        </resource>
    </resources>

targetPath是build的目标文件夹,directory的源文件文件夹,filtering指是否加过滤条件,如果不加,那就false即可,如需要过滤,还需要配置对应过滤文件的位置

刚开始的时候采用的相对路径,结构build多次,发现搞不定,最后使用了绝对路径,搞定了,build完全通过。

最后是maven的war包插件配置:

        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-war-plugin</artifactId>
            <version>3.0.0</version>
        </plugin>

4、用maven构建项目

IDE就提供maven构建的操作界面,找到并测试一下clean  compile 以及package命令,clean是为了不让既有文件影响编译打包结果,很重要。compile是为了避免基础的语法错误,package才是这一阶段的目标——war文件生成。

5、在Jenkins构建对应项目

配置完上述的内容之后,在Jenkins的对应job内更新对应的配置,然后点击立即构建,查看控制台输出就能看到对应的结果,如果项目在本地build都通不过,那在Jenkins服务器上也通不过,通过了说明你Jenkins的job配置可能有问题,或者目标物不对,大坑还没发现,等我跳!

 

Tips:这一节是关于maven的一点小心得,不成大器,但是还能用,需要详细的资料的话,需要阅读更多的文档,祝你好运。

Maven的pom.xml文件详解——Build Settings【转】

By | 2017-03-11

本文转载自:http://blog.csdn.net/tomato__/article/details/13625497

根据POM 4.0.0 XSD,build元素概念性的划分为两个部分:BaseBuild(包含poject build和profile build的公共部分,见下)和poject build包含的一些高级特性。

  1. <projectxmlns=”http://maven.apache.org/POM/4.0.0″
  2. xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
  3. xsi:schemaLocation=”http://maven.apache.org/POM/4.0.0
  4. http://maven.apache.org/xsd/maven-4.0.0.xsd”>
  5. <!– “Project Build” contains more elements than just the BaseBuild set –>
  6. <build></build>
  7. <profiles>
  8. <profile>
  9. <!– “Profile Build” contains a subset of “Project Build”s elements –>
  10. <build></build>
  11. </profile>
  12. </profiles>
  13. </project>

BaseBuild元素集合

basic elements

  1. <build>
  2. <defaultGoal>install</defaultGoal>
  3. <directory>${basedir}/target</directory>
  4. <finalName>${artifactId}-${version}</finalName>
  5. <filters>
  6. <filter>filters/filter1.properties</filter>
  7. </filters>
  8. </build>

1、defaultGoal:执行build任务时,如果没有指定目标,将使用的默认值,如:在命令行中执行mvn,则相当于执行mvn install;
2、directory:build目标文件的存放目录,默认在${basedir}/target目录;
3、finalName:build目标文件的文件名,默认情况下为${artifactId}-${version};
4、filter:定义*.properties文件,包含一个properties列表,该列表会应用的支持filter的resources中。也就是说,定义在filter的文件中的”name=value”值对会在build时代替${name}值应用到resources中。Maven的默认filter文件夹是${basedir}/src/main/filters/。

resources

build的另一个特征是指定你的项目中resources的位置。resources(通常)不是代码,他们不被编译,但是被绑定在你的项目或者用于其它什么原因,例如代码生成。

  1. <build>
  2. <resources>
  3. <resource>
  4. <targetPath>META-INF/plexus</targetPath>
  5. <filtering>false</filtering>
  6. <directory>${basedir}/src/main/plexus</directory>
  7. <includes>
  8. <include>xml</include>
  9. </includes>
  10. <excludes>
  11. <exclude>**/*.properties</exclude>
  12. </excludes>
  13. </resource>
  14. </resources>
  15. <testResources>
  16. </testResources>
  17. </build>

1、resources:一个resource元素的列表,每一个都描述与项目关联的文件是什么和在哪里;
2、targetPath:指定build后的resource存放的文件夹。该路径默认是basedir。通常被打包在JAR中的resources的目标路径为META-INF;
3、filtering:true/false,表示为这个resource,filter是否激活。
4、directory:定义resource所在的文件夹,默认为${basedir}/src/main/resources;
5、includes:指定作为resource的文件的匹配模式,用*作为通配符;
6、excludes:指定哪些文件被忽略,如果一个文件同时符合includes和excludes,则excludes生效;
7、testResources:定义和resource类似,但只在test时使用,默认的test resource文件夹路径是${basedir}/src/test/resources,test resource不被部署。

Plugins

  1. <build>
  2. <plugins>
  3. <plugin>
  4. <groupId>apache.maven.plugins</groupId>
  5. <artifactId>maven-jar-plugin</artifactId>
  6. <version>0</version>
  7. <extensions>false</extensions>
  8. <inherited>true</inherited>
  9. <configuration>
  10. <classifier>test</classifier>
  11. </configuration>
  12. <dependencies></dependencies>
  13. <executions></executions>
  14. </plugin>
  15. </plugins>
  16. </build>

除了groupId:artifactId:version标准坐标,plugin还需要如下属性:
1、extensions:true/false,是否加载plugin的extensions,默认为false;
2、inherited:true/false,这个plugin是否应用到该POM的孩子POM,默认true;
3、configuration:配置该plugin期望得到的properies,如上面的例子,我们为maven-jar-plugin的Mojo设置了classifier属性;

如果你的POM有一个parent,它可以从parent的build/plugins或者pluginManagement集成plugin配置。

为了阐述继承后的关系,考虑如果parent POM中存在如下plugin:

  1. <plugin>
  2. <groupId>group</groupId>
  3. <artifactId>my-plugin</artifactId>
  4. <configuration>
  5. <items>
  6. <item>parent-1</item>
  7. <item>parent-2</item>
  8. </items>
  9. <properties>
  10. <parentKey>parent</parentKey>
  11. </properties>
  12. </configuration>
  13. </plugin>

然后在继承的孩子POM中做如下配置:

  1. <prename=”code” class=”html”><plugin>
  2. <groupId>group</groupId>
  3. <artifactId>my-plugin</artifactId>
  4. <configuration>
  5. <items>
  6. <item>child-1</item>
  7. </items>
  8. <properties>
  9. <childKey>child</childKey>
  10. </properties>
  11. </configuration>
  12. </plugin></pre>

这样孩子POM和parent POM中都存在groupId为my.group的plugin,Maven默认的行为将是根据属性名称将两个plugin的configuration的内容进行合并。如果孩子POM中有一个属性,则该属性是有效的,如果孩子POM中没有一个属性,但parent POM中存在,则parent中的属性是有效的。

根据这些规则,上面的例子在Maven中将得到:

  1. <prename=”code” class=”html”><plugin>
  2. <groupId>group</groupId>
  3. <artifactId>my-plugin</artifactId>
  4. <configuration>
  5. <items>
  6. <item>child-1</item>
  7. </items>
  8. <properties>
  9. <childKey>child</childKey>
  10. <parentKey>parent</parentKey>
  11. </properties>
  12. </configuration>
  13. </plugin></pre>

通过在configuration元素中增加combine.children和combine.self属性,孩子POM可以控制Maven怎么合并plugin的configuration。

假定这儿是孩子POM的configuration:

  1. <prename=”code” class=”html”><configuration>
  2. <items children=”append”>
  3. <!– combine.children=”merge” is the default –>
  4. <item>child-1</item>
  5. </items>
  6. <properties self=”override”>
  7. <!– combine.self=”merge” is the default –>
  8. <childKey>child</childKey>
  9. </properties>
  10. </configuration></pre>

则,现在合并后的效果如下:

  1. <prename=”code” class=”html”><configuration>
  2. <items children=”append”>
  3. <item>parent-1</item>
  4. <item>parent-2</item>
  5. <item>child-1</item>
  6. </items>
  7. <properties self=”override”>
  8. <childKey>child</childKey>
  9. </properties>
  10. </configuration></pre>

combine.children=”append”表示父POM和子POM的属性合并起来;

combine.self=”override”表示子POM的属性完全覆盖父POM的。

4、dependencies:同base build中的dependencies有同样的结构和功能,但这里是作为plugin的依赖,而不是项目的依赖。
5、executions:plugin可以有多个目标,每一个目标都可以有一个分开的配置,甚至可以绑定一个plugin的目标到一个不同的阶段。executions配置一个plugin的目标的execution。

假定一项绑定antrun:run目标到verify阶段,我们希望任务响应build文件夹,同时避免传递配置到他的孩子POM。你将得到一个execution:

  1. <prename=”code” class=”html”><build>
  2. <plugins>
  3. <plugin>
  4. <artifactId>maven-antrun-plugin</artifactId>
  5. <version>1</version>
  6. <executions>
  7. <execution>
  8. <id>echodir</id>
  9. <goals>
  10. <goal>run</goal>
  11. </goals>
  12. <phase>verify</phase>
  13. <inherited>false</inherited>
  14. <configuration>
  15. <tasks>
  16. <echo>Build Dir: ${project.build.directory}</echo>
  17. </tasks>
  18. </configuration>
  19. </execution>
  20. </executions>
  21. </plugin>
  22. </plugins>
  23. </build></pre>

id:标识,用于和其他execution区分。当这个阶段执行时,它将以这个形式展示:[plugin:goal execution: id]。在这里为: [antrun:run execution: echodir];

goals:一个plugin的execution的目标列表;

phase:目标执行的阶段,具体值看Maven的生命周期列表;

inherited:是否继承;

configuration:在指定的目标下的配置。

Plugin Management

pluginManagement的元素的配置和plugins的配置是一样的,只是这里的配置只是用于集成,在孩子POM中指定使用。例如,在父POM中做如下配置:

  1. <build>
  2. <pluginManagement>
  3. <plugins>
  4. <plugin>
  5. <groupId>apache.maven.plugins</groupId>
  6. <artifactId>maven-jar-plugin</artifactId>
  7. <version>2</version>
  8. <executions>
  9. <execution>
  10. <id>pre-process-classes</id>
  11. <phase>compile</phase>
  12. <goals>
  13. <goal>jar</goal>
  14. </goals>
  15. <configuration>
  16. <classifier>pre-process</classifier>
  17. </configuration>
  18. </execution>
  19. </executions>
  20. </plugin>
  21. </plugins>
  22. </pluginManagement>
  23. </build>

则在孩子POM中,我们只需要配置:

  1. <build>
  2. <plugins>
  3. <plugin>
  4. <groupId>apache.maven.plugins</groupId>
  5. <artifactId>maven-jar-plugin</artifactId>
  6. </plugin>
  7. </plugins>
  8. </build>

这样就可以大大的简化孩子POM中的配置。

Reporting

Reporting包含的属性对应到site阶段(见Maven生命周期)。特定的Maven插件能产生定义和配置在reporting元素下的报告,例如:产生Javadoc报告。

  1. <reporting>
  2. <outputDirectory>${basedir}/target/site</outputDirectory>
  3. <plugins>
  4. <plugin>
  5. <artifactId>maven-project-info-reports-plugin</artifactId>
  6. <version>0.1</version>
  7. <reportSets>
  8. <reportSet></reportSet>
  9. </reportSets>
  10. </plugin>
  11. </plugins>
  12. </reporting>

对于reportSets:

  1. <reportSets>
  2. <reportSet>
  3. <id>sunlink</id>
  4. <reports>
  5. <report>javadoc</report>
  6. </reports>
  7. <inherited>true</inherited>
  8. <configuration>
  9. <links>
  10. <link>http://java.sun.com/j2se/1.5.0/docs/api/</link>
  11. </links>
  12. </configuration>
  13. </reportSet>
  14. </reportSets>