课程概要:
- jenkins 概述与环境配置
- 基于jenkins 实现可持续化集成
- jenkins pipeline 核心应用
一、jenkins 概述与环境配置
知识点:
- 关于可持续化集成 (CI)(Continuous integration,简称CI)
- jenkins 概述
- 下载安装jenkins
- 基础环境配置与常用插件下载
1、关于可持续化集成
相信大家都知道jenkins是用来做可持续集成的? 但问题是很多人并不明白什么叫可持续化集成。讲概念之前我们先来举一个场景:
一个团队正着手开发一个项目,在需求评审之后由小组长把项目拆成了若干个模块,分给不同的小伙伴去实现。2个星期以后各自模块的功能都实现了,大家都很开心。这时该合在一起提测了吧。这一合小组长傻眼了,功能没一个能用的,要么公共类冲突了,要么配置冲突....
经过上次的教训,小组长变聪明了,在也不等功能开发之后在合并提测了,而是每天集成提测,如果发现冲突当天就要解决。
持续集成即 Continuous integration(CI) 是一种软件开发实践,即团队开发成员经常集成他们的工作,每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽快地发现集成错误,让团队能够更高效的开发软件。
持续集成要点:(用Jenkins自动构建的话,如果项目是完全独立的,没有私服也行,如果项目是互相依赖的,有的项目是jar包被别的项目使用,则必须有自己的私服。)
- 统一的代码库(git)
- 统一的依赖包管理(nexus)
- 测试自动化
- 构建全自动化(maven)
- 部署自动化
- 可追踪的集成记录
2、jenkins 概述
jenkins 就是为了满足上述持续集成的要点而设计的一款工具,其主体框架采用JAVA开发,实质内部功能都是由各种插件实现,极大提高了系统的扩展性。其不仅可以满足JAVA系统的集成,也可以实现PHP等语言的集成发布。通过其pipeline 插件,用户可以随自己需要定制集成流程。
3、下载安装jenkins
下载:jenkins 支持Docker、yum、msi 等安装,在这里推荐大家直接选择下载他对应的WAR包进行安装。https://jenkins.io/download/
启动:下载完成之后直接可通过 jar -jar 命令启动(表面上是个war包,实际是个jar包。)
java -jar jenkins.war --httpPort=8080(运行war包,并设置端口号。)
也可以将其放至到servlet容器(tomcat\jetty\jboss)中直接启动,无需过多的配置,一切插件化这是jenkins 比较优秀的设计。
配置:下载完成之后进入启动页(http://127.0.0.1:8080/) 会有一个 验证过程,验证码存储在 ${user_home}\.jenkins\secrets\initialAdminPassword
4、基础环境配置与常用插件下载
在集成的时候,jenkins 用到了 Maven 、Git 所以服务器中必须提前安装好这些环境,具体参照前面的git与maven 课程。
邮件配置:
Default Subject
构建通知:$PROJECT_NAME - Build # $BUILD_NUMBER - $BUILD_STATUS!
Default Content
<hr/>
(本邮件是程序自动下发的,请勿回复!)<br/><hr/>
项目名称:$PROJECT_NAME<br/><hr/>
构建编号:$BUILD_NUMBER<br/><hr/>
构建状态:$BUILD_STATUS<br/><hr/>
触发原因:${CAUSE}<br/><hr/>
构建日志地址:<a href="${BUILD_URL}console">${BUILD_URL}console</a><br/><hr/>
构建地址:<a href="$BUILD_URL">$BUILD_URL</a><br/><hr/>
变更集:${JELLY_SCRIPT,template="html"}<br/><hr/>
插件下载
基本插件列表
插件名称 | 插件描述 |
Maven Integration | maven 管理插件 |
Deploy to container | 容器部署插件 |
Pipeline | 管道集成插件 |
Email Extension | 邮件通知插件 |
SSH | 用于ssh 通信 |
二、基于jenkins 实现可持续化集成
知识点:
- 持续化集成完成的目标
- 持续化集成配置
- 集成实现原理
1、 持续化集成完成的目标
需要到达的目标如下:
- 自动基于分支构建项目
- 构建好的项目自动部署至Tomcat容器
- 构建好的项目自动上传至Nexus 私服存档
- 保存构建历史记录,并可以下载历史记录
2、持续化集成配置
(1)、 新建maven job(新建任务。下图中构建一个maven项目的选项,必须安装了上面的maven插件之后才会有这个选项。)
(2)、配置checkout 源码(图中说明错了,不是自动。)
配置源码地址还需要设置能访问仓库的用户名密码,或者直接给Jenkins服务器地址在git上设置公钥。指定分支是master还是哪个。
(3)、 编写 maven构建 命令(构建环境页签下。要执行的maven的参数:clean install –U是强制更新。保存之后此时就可以自动构建了。)(clean install -Dmaven.test.skip=true)
(4)、 自动部署至Tomcat配置(按下图设置好之后保存,再构建就会自动部署了。但这种部署只是简单的,实际公司不会这么部署,因为不安全,会把tomcat下的webapps目录及其下的删掉,并不会有manager目录,那些东西不安全。)
添加构建后操作:Deploy war/ear to container 项目
自动部署的前提条件:
- 需要下载 Deploy to container 插件
- 设置Tomcat manager 用户和密码,以下配置加入至 Tomcat conf/tomcat-users.xml 中
- tomcat webapp 中必须保留 manager 项目
<role rolename="admin-gui"/>
<role rolename="manager-gui"/>
<role rolename="manager-script"/>
<user username="manager" password="manager" roles="manager-gui,manager-script"/>
<user username="admin" password="admin" roles="admin-gui,manager-gui"/>
(5)、 存档配置(对于项目之间有依赖关系的负责构建,需要把优先构建的jar包之类上传到私服仓库里,供下一个工程构建的时候拉去最新jar包。所以需要设置将构建好的包更新到私服。)
构建后操作添加 Deploy war/ear to a container 项目
上传到snapshots快照仓库还是到releases仓库,是根据版本号后面的后缀是什么匹配的。
配置setting.xml 用于获取上传至nexus 的权限
vim ~/.m2/settings.xml
# 添加一个 server id 与 存档配置当中的repository id 相对应。
<server>
<id>nexusReleases</id>
<username>deployment</username>
<password>111111</password>
</server>
如果有构建不同分支的需求,每次想构建不同分支还得去改配置,比较麻烦。则可以通过参数化构建来实现。
别的配置:
Poll SCM,触发器配置
H/30 23 * * 1-5 表示星期一到星期五每天晚上23:30分构建一次。
第一个参数代表的是分钟 minute,取值 0~59;
第二个参数代表的是小时 hour,取值 0~23;
第三个参数代表的是天 day,取值 1~31;
第四个参数代表的是月 month,取值 1~12;
第五个参数代表的是星期 week,取值 0~7,0 和 7 都是表示星期天。
如H/5 表示的就是每5分钟检查一次源码变化。
0 * * * * 表示的就是每个小时的第 0 分钟执行构建。
早九晚五 :H 9,17 * * *
每五分钟 H/5 * * * *
每天8点构建一次:0 8 * * *
每天8点~17点,两小时构建一次:0 8-17/2 * * *
周一到周五,8点~17点,两小时构建一次:0 8-17/2 * * 1-5
每月1号、15号各构建一次,除12月:H H 1,15 1-11 *
小时,取值范围(0~23):若其他值不做设定,则表示每个设定小时的每分钟都会构建
如:* 5 * * * ,表示在每天5点的时候,一小时内每一分钟都会构建一次
日期,取值范围(1~31):若其他值不做设定,则表示每个月的那一天每分钟都会构建一次
如:* * 5 * *,表示在每个月5号的时候,0点开始每分钟构建一次
其中每个字段除了可以使用取值范围内的值外,还能使用一些特殊的字符。
* 匹配范围内所有值
M-N 匹配M~N范围内所有值
M-N/X 或者 */X 在指定M~N范围内或整个有效区间内每隔X构建一次
A,B,...,Z 匹配多个值
为了在系统中生成定时任务,符号H(代表“Hash”,后面用“散列”代替)应该用在可能用到的地方,例如:为十几个日常任务配置0 0 * * *将会在午夜产生较大峰值。相比之下,配置H H * * * 仍将每天一次执行每个任务,不是都在同一时刻,可以更好的使用有限资源。
符号H可用于范围,例如,H H(0-7) * * * 代表凌晨0:00到 上午7:59一段时间。你还可以用H代表有或无范围的区间。
符号H 在一定范围内可被认为是一个随机值,但实际上它是任务名称的一个散列而不是随机函数。
需要注意的是,月份中的某天-DOM字段,类似于*/3 或者 H/3 的短周期由于月份的天数不固定,在大多数月尾总不会工作。例如,*/3 将会在一个月里面的第一天、第四天。。。第31天执行,下个月的那天继续重复执行。散列一般被选择在1-28天内,所以H/3将会在跑到月底的3-6天内导致空白。(长时间循环将会导致长度不一,但是这种影响也是不明显的。)
空行和以#开头的行将会被认为是注释。
另外,@yearly, @annually, @monthly, @weekly, @daily, @midnight, 和 @hourly也支持别名。这些使用散列系统自动匹配,例如:@hourly 和 H * * * * 一样代表一个小时内的任何时刻。@midnight实际上代表凌晨0:00到凌晨2:59之间的一段时间。
例如:
# 每隔15分钟。(或许:07, :22, :37, :52)
H/15 * * * *
# 每前半小时中每隔10分钟。 (3次, 或许:04, :14, :24)
H(0-29)/10 * * * *
# 每个工作日从早上9点45分开始到下午3点45分结束这段时间内每间隔2小时的45分钟那一刻。
45 9-16/2 * * 1-5
#每个工作日从早上9点到下午5点这段时间内每间隔2小时之间的某刻。(或许在上午10:38, 下午12:38, 下午2:38 , 下午4:38)
H H(9-16)/2 * * 1-5
Poll SCM:定时检查源码变更(根据SCM软件的版本号),如果有更新就checkout最新code下来,然后执行构建动作。我的配置如下:
*/5 * * * * (每5分钟检查一次源码变化)
Build periodically:周期进行项目构建(它不care源码是否发生变化),我的配置如下:
0 2 * * * (每天2:00 必须build一次源码)
3、集成实现原理
三、jenkins pipeline 核心应用
知识点:
- pipeline 概要
- pipeline 基础语法
- pipeline Demo演示
1、pipeline 概要
前面我们演示的 使用maven 来进行自动化构建,其流程分别是:构建环境准备==》源码下载 ==》构建 ==》存档 ==》部署。这是一种固化的构建流程,如果你们的需求是多个项目需要进行依赖构建这种复杂的构建场景 时该怎么办?jenkins pipeline 可以做到这一点。
Jenkins从根本上讲是一种支持多种自动化模式的自动化引擎。Pipeline在Jenkins上添加了一套强大的自动化工具,支持从简单的连续集成到全面的连续输送Pipeline的用例。用户可以基于他实现更为复杂的建模场景。
2、pipeline 基础语法
以下就是一个非常简单的 pipeline 脚本:
pipeline {
agent any
stages {
stage('Build') {
steps {
sh 'make'
}
}
stage('Test'){
steps {
sh 'make check'
junit 'reports/**/*.xml'
}
}
stage('Deploy') {
steps {
sh 'make publish'
}
}
}
}
agent
stage 描述了这条Pipeline的一个阶段。
steps 描述了要在其中运行的步骤 stage
sh 执行给定的shell命令
junit 是由JUnit插件提供的 用于聚合测试报告的Pipeline步骤。
3、pipeline Demo演示
前提条件
- Jenkins 2.x或更高版本
- Pipeline插件
可以通过以下任一方式创建基本Pipeline:
- 直接在Jenkins网页界面中输入脚本。
- 通过创建一个Jenkinsfile可以检入项目的源代码管理库。
用任一方法定义Pipeline的语法是一样的,从项目源码中检入jenkinsfile 文件会更方便一些。
基于脚本构建 pipeline
pipeline {
agent any
stages {
stage('Checkout') {
steps {
echo 'Checkout'
}
}
stage('Build') {
steps {
echo 'Building'
}
}
stage('test'){
steps{
echo 'test'
}
}
}
}
基于Jenkinsfile 构建
pipeline {
agent any
stages {
stage('Checkout') {
steps {
echo 'Checkout'
checkout([$class: 'GitSCM', branches: [[name: '*/dev_2.1.X']], doGenerateSubmoduleConfigurations: false, extensions: [], submoduleCfg: [], userRemoteConfigs: [[credentialsId: 'd87db753-4d22-4a06-944e-6576656ff6e5', url: 'git@192.168.254.128:YUSP/yusp-registry.git']]])
}
}
stage('Build') {
steps {
echo 'Building'
sh 'mvn clean install'
}
}
stage('save'){
steps{
echo 'save'
archiveArtifacts '**/target/*.jar'(经idea中package打包实验,打出的是jar包,且路径为:D:\yuxinWorkspace\yusp-registry\registry-server-eureka\target\registry-server-eureka.jar,所以包不在根路径下,此处还可直接配registry-server-eureka/target/*.jar)
}
}
stage('email'){
steps{
echo 'email'
mail bcc: '', body: 'OK啦2', cc: '', from: '', replyTo: '', subject: '构建', to: 'wangxm9@yusys.com.cn'
}
}
}
}
pipeline {
agent any
stages {
stage('checkout') {
steps {
echo 'checkout'
checkout([$class: 'GitSCM', branches: [[name: '*/master']], doGenerateSubmoduleConfigurations: false, extensions: [], submoduleCfg: [], userRemoteConfigs: [[credentialsId: 'gogs_luban', url: 'http://git.jiagouedu.com/java-vip/tuling-api-gateway']]])
}
}
stage('build'){
steps {
echo 'build'
sh 'mvn clean install'
}
}
stage('save') {
steps {
echo 'save'
archiveArtifacts 'target/*.war'
}
}
}
}