（三）手把手教你搭建Jenkins、gitlab，实现自动化部署配置测试报告发送邮件到指定用户

一、jenkins 介绍

1.背景

在实际开发中，我们经常要一边开发一边测试，当然这里说的测试并不是程序员对自己代码的单元测试，而是同组程序员将代码提交后，由测试人员测试；或者前后端分离后，经常会修改接口，然后重新部署；这些情况都会涉及到频繁的打包部署；
　　手动打包常规步骤： 1.提交代码　　2.问一下同组小伙伴有没有要提交的代码　　3.拉取代码并打包（war包，或者jar包）　　4.上传到Linux服务器　　5.查看当前程序是否在运行　　6.关闭当前程序　　7.启动新的jar包　　8.观察日志看是否启动成功　　9.如果有同事说，自己还有代码没有提交……再次重复1到8的步骤！！！！！（一上午没了）　　
　　那么，有一种工具能够实现，将代码提交到git后就自动打包部署勒，答案是肯定的：Jenkins　　当然除了Jenkins以外，也还有其他的工具可以实现自动化部署，如Hudson等　　只是Jenkins相对来说，使用得更广泛。
　　

1.1 Jenkins是什么

Jenkins是一个开源软件项目，是基于Java开发的一种持续集成工具，用于监控持续重复的工作，可用于自动执行与构建，测试，交付或部署软件相关的各种任务，一款能提高效率的软件，它能把软件开发过程形成工作流。jenkisn使开发者从繁杂的集成中解脱出来，专注于更为重要的业务逻辑实现上。同时 Jenkins 能实施监控集成中存在的错误，提供详细的日志文件和提醒功能，还能用图表的形式形象地展示项目构建的趋势和稳定性。

1.2 Jenkins作用

持续、自动地构建/测试软件项目。
监控一些定时执行的任务。

1.3 Jenkins特性

• 开源的java语言开发持续集成工具，支持CI，CD。（详解：https://editor.csdn.net/md?not_checkout=1&articleId=115718484）
• 易于安装部署配置：可通过yum安装,或下载war包以及通过docker容器等快速实现安装部署，可方便web界面配置管理。
• 消息通知及测试报告：集成RSS/E-mail通过RSS发布构建结果或当构建完成时通过e-mail通知，生成JUnit/TestNG测试报告。
• 分布式构建：支持Jenkins能够让多台计算机一起构建/测试
• 文件识别:Jenkins能够跟踪哪次构建生成哪些jar，哪次构建使用哪个版本的jar等。
• 丰富的插件支持:支持扩展插件，你可以开发适合自己团队使用的工具，如git，svn，maven，docker等。

1.4 Jenkins的工作原理

目前持续集成(CI)已成为当前许多软件开发团队在整个软件开发生命周期内侧重于保证代码质量的常见做法。它是一种实践，旨在缓和和稳固软件的构建过程。并且能够帮助您的开发团队应对如下挑战：

• 软件构建自动化 ：配置完成后，CI系统会依照预先制定的时间表，或者针对某一特定事件，对目标软件进行构建。
• 构建可持续的自动化检查 ：CI系统能持续地获取新增或修改后签入的源代码，也就是说，当软件开发团队需要周期性的检查新增或修改后的代码时，CI系统会不断确认这些新代码是否破坏了原有软件的成功构建。这减少了开发者们在检查彼此相互依存的代码中变化情况需要花费的时间和精力
• 构建可持续的自动化测试 ：构建检查的扩展部分，构建后执行预先制定的一套测试规则，完成后触发通知(Email,RSS等等)给相关的当事人。
• 生成后后续过程的自动化 :当自动化检查和测试成功完成，软件构建的周期中可能也需要一些额外的任务，诸如生成文档、打包软件、部署构件到一个运行环境或者软件仓库这样，构件才能更迅速地提供给用户
• 使用部署一个CI系统需要的最低要求是，一个可获取的源代码的仓库，一个包含构建脚本的项目

持续集成得过程： 先把代码放到git、Jenkins从git获取代码进行构建、测试、生成结果再返回给客户端。

该系统的各个组成部分是按如下顺序来发挥作用的：

• 开发者检入代码到源代码仓库
• CI系统会为每一个项目创建了一个单独的工作区。当预设或请求一次新的构建时，它将把源代码仓库的源码存放到对应的工作区。
• CI系统会在对应的工作区内执行构建过程。
• （配置如果存在）构建完成后，CI系统会在一个新的构件中执行定义的一套测试。完成后触发通知(Email,RSS等等)给相关的当事人。
• （配置如果存在）如果构建成功，这个构件会被打包并转移到一个部署目标(如应用服务器)或存储为软件仓库中的一个新版本。软件仓库可以是CI系统的一部分，也可以是一个外部的仓库，诸如一个文件服务器或者像Java.NET、 SourceForge之类的网站。
• CI系统通常会根据请求发起相应的操作，诸如即时构建、生成报告，或者检索一些构建好的构件。
  Jenkins就是这么一个CI系统。之前叫做Hudson。

1.5 使用Jenkins的一些理由

1. 是所有CI产品中在安装和配置上最简单的。
2. 基于Web访问，用户界面非常友好、直观和灵活，在许多情况下，还提供了AJAX的即时反馈。
3. Jenkins是基于Java开发的(如果你是一个Java开发人员，这是非常有用的)，但它不仅限于构建基于Java的软件。
4. Jenkins拥有大量的插件。这些插件极大的扩展了Jenkins的功能；它们都是开源的，而且它们可以直接通过web界面来进行安装与管理。

二、Jenkins的安装

2.1 Jenkins部署环境

搭建配置所需要的基本环境：　　
1.jdk环境，Jenkins是java语言开发的，因需要jdk环境。
2.git/svn客户端，因一般代码是放在git/svn服务器上的，我们需要拉取代码。　
3.maven客户端，因一般java程序是由maven工程，需要maven打包，当然也有其他打包方式，如：gradle　　
以上是自动化部署java程序jenkins需要的基本环境，请自己提前安装好，下面着重讲解Jenkins的安装部署配置。

2.2.Jenkins安装

jenkins 的安装有很多种，具体可以参照官方文档 https://jenkins.io/download/ ，因为我的操作系统是redhat 7，我这里使用 rpm 包进行安装，方便快捷。

• 首先安装jdk环境：
  
  查看安装版本

[root@jenkins ~]# java -version java version “1.8.0_181” Java™ SE
Runtime Environment (build 1.8.0_181-b13) Java HotSpot™ 64-Bit
Server VM (build 25.181-b13, mixed mode)

• jenkins 的rpm包下载
  官网找到 RedHat 的地址：https://pkg.jenkins.io/redhat-stable/ 。
  下载rpm包：wget https://pkg.jenkins.io/redhat/ jenkins-2.155-1.1.noarch.rpm

• 安装 Jenkins

[root@localhost local]# rpm -ivh jenkins-2.155-1.1.noarch.rpm warning:
jenkins-2.155-1.1.noarch.rpm: Header V4 DSA/SHA1 Signature, key ID
d50582e6: NOKEY Preparing…
########################################### [100%] 1:jenkins ########################################### [100%]

看 jenkins 安装了哪些文件，目录介绍：

[root@localhost local]#rpm -ql jenkins
/etc/init.d/jenkins                #jenkins的启动文件
/etc/logrotate.d/jenkins
/etc/sysconfig/jenkins             #jenkins的配置文件（可以写改默认端口）
/usr/lib/jenkins                  
/usr/lib/jenkins/jenkins.war  #jenkins的程序war包
/usr/sbin/rcjenkins                #jenkins的为二进制文件
/var/cache/jenkins                 #jenkins的程序文件，运行程序解压出来的
/var/lib/jenkins                   #jenkins的主目录
/var/log/jenkins                   #jenkins的日志文件

• 启动 Jenkins

1.查看服务状态
[root@localhost local]# service jenkins status jenkins 已停
启动 jenkins ：sudo service jenkins start
开机自启动 ：sudo chkconfig jenkins on

启动报如下错误：Starting Jenkins bash: /usr/bin/java: No such file or directory
2.修改Jenkins启动配置文件，指定java安装路径。

vim /etc/init.d/jenkins
在candidates中第一行添加java路径，如下：
candidates="
/usr/local/jdk1.8.0_191/bin/java
/etc/alternatives/java
/usr/lib/jvm/java-1.6.0/bin/java
/usr/lib/jvm/jre-1.6.0/bin/java
/usr/lib/jvm/java-1.7.0/bin/java
/usr/lib/jvm/jre-1.7.0/bin/java
/usr/lib/jvm/java-1.8.0/bin/java
/usr/lib/jvm/jre-1.8.0/bin/java
/usr/bin/java
"
再次启动jenkins
[root@localhost local]# service jenkins start
Starting Jenkins [确定]

3.防火墙

修改防火墙允许8080端口访问：firewall-cmd --zone=public --add-port=8080/tcp --permanent
重启防火墙生效：systemctl restart firewalld.service
查看所有打开的端口： firewall-cmd --zone=public --list-ports

4.修改jenkins端口

vim /etc/sysconfig/Jenkins
JENKINS_PORT=”8080″ 改成 JENKINS_PORT=”8888″ 默认8080端口，不冲突可以不修改
保存，重启jenkins服务：service jenkins restart
设置防火墙允许8888端口访问：firewall-cmd --zone=public --add-port=8888/tcp --permanent
这样jenkins端口就改成了8888
#查看端口是否已启动
[root@localhost local]# netstat -lunpt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1068/sshd
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1144/master
tcp 0 0 :::8888 :: LISTEN 1523/java
tcp 0 0 :::22 :: LISTEN 1068/sshd
tcp 0 0 ::1:25 :: LISTEN 1144/master
udp 0 0 0.0.0.0:68 0.0.0.0:* 954/dhclient

5.修改jenkins默认的操作用户

linux下jenkins默认使用jenkins用户进行脚本和文件的操作，如果不修改，在部署项目时需要调整涉及到的文件和目录的操作权限，可以调整jenkins配置文件，将用户修改为root用户。
vim /etc/sysconfig/jenkins
将JENKINS_USER="jenkins"调整为 JENKINS_USER=“root”

6.在本地浏览器中输入“http://IP:端口号”登录 jenkins，第一次登录Jenkins 会要求解锁

初始密码：cat /var/lib/jenkins/secrets/initialAdminPassword

7.安装插件

8. 设置管理员账户密码

9.完成安装

2.3 Jenkins的插件以及配置

插件管理

jenkins系统管理比较重要的就是插件管理了 ，因为jenkins的工作全部是由插件来完成。

在插件管理中，有可更新、可选插件、已安装，日常的插件安装都是在这个界面上完成的。比如为了和gitlab协同，我们需要安装gitlab的插件。

它包含四个标签：

• 更新:清单中列示了Jenkins为某些插件搜索到了可用的更新。列出的每个插件可以被选择并应用更新。
• 可选安装:清单中列示了可用于安装（而不是目前已安装的）的所有插件。列出的每个插件都可以被选择并安装。
• 已安装:清单中列示了已经安装的插件。
• 高级:允许您通过设定HTTP代理的方式使Jenkins与在线插件库建立连接。
  此外，还提供了一个上传设备，可以安装你在Jenkins以外已下载的那些插件，如图：
  
  代理的设置，在服务器目录下进行上传插件，目录路径= /var/lib/jenkins/plugins/ ，这个目录下是我们安装所有的插件。

解决插件安装失败问题

有很多插件没有安装成功，可以将相应的插件下载到本地，然后导入到jenkins插件目录 ，
jenkins安装插件的目录在/var/lib/jenkins/plugins下

下载地址：http://updates.jenkins-ci.org/

将插件压缩包传到jenkins的插件目录解压，并修改属主属组

解    压：tar –zxvf plugin.tar.gz

备    份：mv  plugins  /var/lib/jenkins/

修改属主属组：chown  -R  jenkins.jenkins plugins/

重启jenkins：service jenkins restart

配置管理

系统配置

执行者数量：配置并发数量，一般设置为5，不超过10

用法：如果是主server，可以不选，如果是从级别必须选择“尽可能的使用这个节点”

生成前等待时间：配置该时间10s，避免错误操作，有时间返回

SCM签出重试次数：一般我们使用jenkins 从gitlab拉取代码, 然后使用再执行, 但是 免不了gitlab因为服务器配置差, 导致最终拉取失败,重试次数=1, 这样, 我们有1次机会去拉取失败

配置Jenkins域名-ip


配置邮件发送


全局工具配置
执行命令：where git ，就会显示git的安装路径了

三、gitlab安装

3.1 安装gitlab服务

下载gitlab包: https://packages.gitlab.com/gitlab/gitlab-ce
下载的包文件存放在/usr/local目录下

安装：

[root@gitlab src]# rpm -ivh gitlab-ce-11.5.2-ce.0.el6.x86_64.rpm

[root@gitlab src]# vim /etc/gitlab/gitlab.rb
external_url 'http://ip：port' #访问地址：可以写主机名或ip地址

修改配置文件/etc/gitlab/gitlab.rb

修改配置文件后执行重载指令 ，重载指令执行需要一段时间 ：gitlab-ctl reconfigure

3.2 gitlab和gitlab Hook Plugin插件

确认gitlab和gitlab Hook Plugin两个关键插件是否安装，没有安装则可以在线安装

这两个插件很重要，gitlab是从gitlab服务器端获取代码的插件，gitlab Hook Plugin 是触发jenkins构建项目的插件，如果没有这个插件，那么未经测试的代码直接就发布到生产环境中去了

3.3 配置jenkins和gitlab关联

jenkins要从gitlab上获取代码，因此两者之间要基于key认证，将jenkins生成的公钥配置在gitlab中，gitalb指定某个用户对某个项目有操作权限。

1. 在gitlab上新建一个用户，他属于myweb组
   
2. 后面在jenkins上要使用这个用户来进行测试发布
3. jenkins上生成秘钥，将公钥复制到gitlab中的myweb项目中
   [root@jenkins ~]# cat ~/.ssh/id_rsa.pub
4. 在gitlab的project中，找到Deploy keys，将上面jenkins的公钥加入到上面
   
5. jenkins用ssh的方式向gitlab拉取文件
6. jenkins通过配置用户拉取代码默认会保存在/var/lib/jenkins/workspace/目录下
7. 将jenkins私钥配置到jenkins的服务中，（gitlab放公钥，jenkins放私钥）
   
   进入之后点击“Add Credentials”添加私钥：如下图，点击OK保存

至此jenkins与gitlab关联和配置就做好了，接下来就可以在jenkins中构建项目了，通常我们构建一个自由风格的项目

四、创建一个自由风格的项目

4.1 新建任务

输入任务名称和选择任务类型

4.2 配置项目

Jenkins在每一次的执行构建后，都会对该构建的项目生成一个历史构建记录以及生成一份历史构建的项目发布包，刚开始的时候大家都不在意，毕竟一次构建比原项目也大不了多少，所以说没有人会关心磁盘的占用问题，但是随着时间的推移，要构建的项目越来越多，而构建的历史版本同样也越来越多，这过多的项目外加每个项目的过多的版本，其最终的结果就是磁盘被占用的空间越来越大，直至磁盘空间被占用完为止，最终可怕的结果可想而知，由于没有再可以被写入的空间，其它软件也就无法正常运行了。
图示为只保留最近3天内的10个构建历史，避免一直保留沾满磁盘。

为了一个自动化项目中同时包含多个不同的子项目，可以按照需求单独执行子项目，
配置参数化构建过程

下图为distribution_demo_qa.xml文件在项目中的位置，会起文介绍testng测试框架。【传送门预留】

对应构建shell命令配置

4.2.1 选择代码托管

在源码管理工具（Source Code Management）中选择Git，添加Git仓库、添加Git证书、选择一个分支：

4.2.2 添加认证

证书的添加可以直接点击add添加

进入页面后，可以选择 Username with password 或者 SSH Username with private key, 根据你的情况选择。

私钥 ：cat ~/.ssh/id_rsa

也可以在系统管理—>凭据中添加。

4.2.3 构建触发器

（1）其他工程构建后触发（build after other projects are built）：在其他项目触发的时候触发，里面有分为三种情况，也就是其他项目构建成功、失败、或者不稳定的时候触发项目

（2）定时构建（build periodically）：隔一段时间build一次，不管版本库代码是否发生变化。

* * * * *

第一个 * 表示分钟，取值0~59
第二个 * 表示小时，取值0~23
第三个 * 表示一个月的第几天，取值1~31
第四个 * 表示第几月，取值1~12
第五个 * 表示一周中的第几天，取值0~7，其中0和7代表的都是周日
Jenkins定时语法：

跟cron定时任务语法基本类似

一、字段有哪些
每行包含5个字段，用制表符或空格隔开，从左至右依次是：

分 时 天 月 星期

二、每个字段的取值范围
分钟 (0–59)
时 (0–23)
天 (1–31)
月 (1–12)
星期 (0 和 7 都代表星期日)
三、为了每个字段可以取多个值，可以用下面操作符，按优先顺序：
• * 匹配范围内所有值
• M-N 匹配(M~N范围内的所有值)
• M-N/X or * /X 在指定区间（M~N）或者整个有效区间 * 内，每隔 X 构建一次
• A,B,...,Z 匹配多个值

四、符号 H 的用法
为了在系统中产生均匀的计划任务， 尽可能的使用符合H（就是Hash）
例如， 用 0 0 * * * 来执行十几个任务，将会在午夜产生较大的峰值，
相反， 用 H H * * * 在一天中仍然会执行每一个任务, 但是并不在同一时间去做，可以更好的利用有限的资源。

符号H可以用作一个范围.
例如， H H(0-7) * * * 代表着在凌晨0:00 到早上7:59的这段时间， 你还可以用H 代表有范围或者无范围中的 区间。

H可以被当做一个范围内的随机值，实际上，它是一个任务的hash，并不是一个随机函数，所以对于任务项目来说， 这个值都是稳定的。

要注意在一个月中天的字段，短周期内例如 * /3 或者 H/3 将在接近月末的时候，因为月长的不固定，工作会不稳定。
例如，* /3 将会在一个31天的月中，第1天、第4天、第7天......、第28天、第31天执行构建，然后再下一个月继续重复执行，
hash常常会选择范围1~28天内执行，所以，H/3 在月末的3~6天里，产生运行间隙（长时间循环导致长度不一致，但是这个影响相对来说不明显）

空行 和 以 #开头的被视为 注释

一些别名
@yearly, @annually, @monthly, @weekly, @daily, @midnight, and @hourly，这些使用系统默认自动匹配的时间。
比如，
@hourly 跟 H * * * * 都表示一个小时之内的任意时间.
@midnight 代表 0:00 AM and 2:59 AM 之间的时间.

例如：
* 每隔15分钟 (或许在 :07、 :22 、:37、 :52)
H/15 * * * *
*每个前半小时之内，每10分钟 (共有三次, 可能在 :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
* 每月（除了12月）从1号到15号这段时间内某刻
H H 1,15 1-11 *

（3）轮询（poll scm）：隔一段时间比较一次源代码如果发生变更，那么就build。否则，不进行build。

（4）远程触发构建（有一种方式是通过配置令牌远程触发项目构建）：

要启用Token(令牌)远程触发项目构建首先要保证Jenkins服务安装了build-token-root 插件，并且配置了Jenkins的身份验证(不是必须)。

打开项目的配置，设置令牌：

通过复制这个URL地址，在别的机器上打开这个URL就相当于给这个jenkins服务器发送了一个构建请求。只不过这个请求是在其他人电脑上发出的，这里重点来看看URL的组成：

第一个参数JENKINS_URL，这里我们写IP地址或者机器hostname

第二个参数TOKEN_NAME就是你在身份验证令牌文本输入框输入的值。这里我们把令牌设置成123456，然后就在机器的另外一个浏览器来模拟远程构建

http://10.101.124.250:8888/job/test_demo/build?token=123456

远程构建地址就是这样的： http://ip:port/job/项目名称/build?token=令牌值，就可以自动构建了。

搭建mock平台维护身份令牌页面点击执行操作，触发get请求，会另外起一文，「传送门」

4.2.4 构建

执行脚本的命令。需要输入相关命令来实现自动化构建

构建执行shell命令需要输入相关命令来实现自动化构建

echo "Start to auto ansenal API"

# 延迟运行CASE，保证服务部署健康检查通过
sleep ${
     BEFORE_RUN_SLEEP}

# 执行测试计划
#分享赚
mvn clean test -Dsurefire.suiteXmlFiles=${
     PLAN_ROOT_PATH}/distribution/${
     DISTRBUTION_PLAN} ||true

echo "End to auto ansenal  API"

4.2.5 构建后操作

配置邮件发送内容与发送人员

（1）构建结果json文件对应工作区的存放位置

• 配置存放位置
  
• 项目存放位置展示
  
• Jenkins结果展示
• 

（二）配置邮件发送人

Project Recipient List：这个项目的需要发送邮件给哪些人，可以在这里输入多个邮箱，中间以英文逗号隔开。
Project Reply-To List：保持默认即可，这个是收到邮件的人回复邮件时候回复给谁用的，一般不会回复邮件。

（三）配置邮件内容

Content Type：可以选择Html格式。
Default Subject： 邮件主题可以书写成：XXX项目自动化测试通知:$PROJECT_NAME - Build # $BUILD_NUMBER - $BUILD_STATUS
对应参数含义
$PROJECT_NAME 构建项目的名称；
$BUILD_NUMBER 构建的号码；
$BUILD_STATUS 构建状态，
这几个参数，它会自动读取，按照这种格式书写即可。
Default Content：邮件内容，这块是重点，最能体现报告的重点，我们需要输入以下内容：

• 邮件html文本贴录

  
<html>  
<head>  
<meta charset="UTF-8">  
<title>${ENV, var="JOB_NAME"}-第${BUILD_NUMBER}次构建日志title>  
head>  

<body leftmargin="8" marginwidth="0" topmargin="8" marginheight="4"  
    offset="0">  
    <div>
    <table width="95%" cellpadding="0" cellspacing="0" 
        style="font-size: 11pt; font-family: Tahoma, Arial, Helvetica, sans-serif"> 

        <tr>
            <th align="center" colspan="2"><br />
                <h2>qa部署自动触发报告h2> 
            th>
        tr>
        <tr>  
            <td>  
                <ul>  
                    <li>项目名称 ： ${PROJECT_NAME}li><br />  
                    <li>详细报告 ： <a href="${PROJECT_URL}${BUILD_NUMBER}/allure/">查看报告a >li><br />
                    <li>触发原因： ${CAUSE}li><br />                    
                    <li>项目  Url ： <a href="${PROJECT_URL}">${PROJECT_URL}a >li><br />
                ul>  
            td> 
        tr>  
    table> 
    div>
  body>  
html>

<-- 说明 -->
触发原因：${CAUSE}<br/><hr/>
测试报告：<a href="http://ip:port/job/$PROJECT_NAME/ws/autotest/result/test-report/power-emailable-report.html">http://ip:port/job/autotest/ws/autotest/result/test-report/power-emailable-report.html a><br/><hr/>
构建日志地址：<a href="${BUILD_URL}console">${BUILD_URL}console/a><br/><hr/>
构建地址：<a href="$BUILD_URL">$BUILD_URLa><br/><hr/>
构建报告：<a href="${BUILD_URL}testReport">${BUILD_URL}testReport/a><br/><hr/>
变更集:${JELLY_SCRIPT,template="html"}<br/><hr/>

其中IP和端口需要修改成自己电脑的信息，这样别人才能访问到jenkins上的测试结果。
最后配置什么时候触发发送邮件操作 ，点击Advanced Settings…，把默认的trigger给删除掉，然后新增一个trigger，然后选择Always选项，如此便不管构建成功还是失败都会发送邮件。

至此，点击应用后保存，项目配置完成！！！

邮件接收效果展示

PROJECT_URL：对应allure 测试报告

4.3 立即构建

保存后返回首页就可以看到刚才创建的项目，可以构建项目测试看一下

4.4 构建结果

构建完后可以查看构建过程中的信息状态，看看是构建成功还是失败

（1）构建状态:

下图中分级符号概述了一个Job新近一次构建会产生的四种可能的状态：

• Successful:完成构建，且被认为是稳定的。
• Unstable:完成构建，但被认为不稳定。
• Failed:构建失败。
• Disabled:构建已禁用。

（2）构建稳定性:
当一个Job中构建已完成并生成了一个未发布的目标构件，如果您准备评估此次构建的稳定性，Jenkins会基于一些后处理器任务为构建发布一个稳健指数 (从0-100 )，这些任务一般以插件的方式实现。
它们可能包括单元测试(JUnit)、覆盖率(Cobertura )和静态代码分析(FindBugs)。
分数越高，表明构建越稳定。下图中分级符号概述了稳定性的评分范围。任何构建作业的状态(总分100)低于80分就是不稳定的

（3）你也可以在当前Job主界面上看到它，如下图左侧栏的链接主要控制Job的配置、删除作业、构建作业。

如果你想通过视图输出界面来监控当前任务的进展情况。你可以单击Console Output（控制台输出）。如果工作已完成，这将显示构建脚本产生的静态输出；如果作业仍然在运行中，Jenkins将不断刷新网页的内容，以便您可以看到它运行时的输出。如下图

可以看到输出信息中最后一行提示为success

五、jenkins的Master/Slave模式

5.1 Master/Slave模式

分担jenkins服务器的压力，任务分配到其它执行机来执行
Master：Jenkins服务器
Slave：执行机(奴隶机)。执行Master分配的任务，并返回任务的进度和结果

工作交互图：

这里是选择Gitlab作为git server。

系统的工作流程大概分为以下几步:

1> 开发者将新版本push到git server (Gitlab)。

2> Gitlab随后触发jenkins master结点进行一次build。(通过定时检测)

3> jenkins master结点将这个build任务分配给若干个注册的slave结点中的一个，这个slave结点根据一个事先设置好的脚本进行build。这个脚本可以做的事情很多，比如编译，测试，生成测试报告等等。这些原本需要手动完成的任务都可以交给jenkins来做。

4> 我们在build中要进行编译，这里使用了分布式编译器distcc来加快编译速度。

5.2 在Master上配置Slave

Jenkins是一个Master-Slave的架构，它可以把任务发布到不同的节点上执行，典型的应用场景是你有2个运行环境，一个是测试环境，一个是生产环境，你可以指定工作流中，哪些任务在测试环境中执行，哪些任务在生产环境中执行。当然，如果你没有这样的需求，也可以不配置Slave。

（1）新建节点

路径：jenkins首页—系统管理—节点管理—节点管理


（2） 设置节点

设置完成点击最下方保存

5.3 启动Slave

（1）此时在节点管理里面看到有一台Slave机，但没在线，现在就开始启动它，点击Slave机的名字

（2） 点击Launch，会下载slave—agent.jnlp文件，注意前提是slave机已安装的jdk版本必须大于等于1.8

（3） 下载完成后双击slave—agent.jnlp，出弹出一个Jenkins agent的小窗口，窗口左上角有个File，点击File，会出现Install as a service，表示安装成windows服务，选择它，运行job时是看不到界面的

（4）再刷新一下，可以看到Slave机红色的 X 没了

六、创建一个Pipeline项目

6.1 Pipeline 定义

脚本Pipeline是用Groovy写的 。因此，当了解Groovy时，不需要使用Pipeline。

可以通过以下任一方式创建基本Pipeline：

直接在Jenkins网页界面中输入脚本。
通过创建一个Jenkinsfile可以检入项目的源代码管理库。
用任一方法定义Pipeline的语法是一样的，但是Jenkins支持直接进入Web UI的Pipeline，通常认为最佳实践是在Jenkinsfile Jenkins中直接从源代码控制中加载Pipeline。

6.2 在Web UI中定义Pipeline

要在Jenkins Web UI中创建基本Pipeline，请按照下列步骤操作：

单击Jenkins主页上的New Item。

输入Pipeline的名称，选择Pipeline，然后单击确定。
Jenkins使用流水线的名称在磁盘上创建目录。包含空格的管道名称可能会发现不希望路径包含空格的脚本中的错误。

在脚本文本区域中，输入Pipeline，然后单击保存。

node 在Jenkins环境中分配一个执行器和工作空间。
echo 在控制台输出中写入简单的字符串

单击立即生成以运行Pipeline。

单击“构建历史记录”下的＃1，然后单击控制台输出以查看Pipeline的完整输出。

6.3 在SCM中定义Pipeline

在刚开始使用Jenkins的时候，大部分的使用方式都是采用FreeStyle进行构建自动化部署的配置，但是随着业务的不断增加与变化也要创建N多个Job来进行管理，甚至当服务器环境迁移之类的事情产生之后发现这种管理方式太过于低效，需要手工来维护这些大量的配置信息，并且相关配置一旦改过之后无法追溯到某个版本，还有脚本的灵活度也不高，所以后来研究使用Pipeline的方式创建Job，然后创建Jenkinsfile文件跟随项目仓库存放，这样灵活度与可追溯性大大加强，利于自动化部署更上一层台阶。

基本环境搭建好后，我们来配置一个工作流亲自感受一下

工作流在Jenkins中被称为pipeline，pipeline的运行行为由用户自己定义，定义的内容存放在一个Jenkinsfile文件中，并将该文件存放在git仓库的根目录

大致的流程如下：

用户将代码提交到git
Jenkins从git拉取最新代码
读取根目录下的Jenkinsfile文件，并依次执行文件中定义的任务

下面是具体的配置步骤，编写Jenkinsfile

pipeline {
    agent {
        label 'Master'
    }
    stages {
        stage('Build') {          
            steps {              
                echo 'Building'          
            }      
        }      
        stage('Test') {          
            steps {               
                echo 'Testing'          
            }      
        }
        stage('Deploy - Staging') {          
            steps {              
                sh './deploy staging'              
                sh './run-smoke-tests'          
            }      
        }      
        stage('Sanity check') {          
            steps {              
                input "Does the staging environment look ok?"          
            }      
        }      
        stage('Deploy - Production') {          
            steps {              
                sh './deploy production'          
            }      
        }  
    }
    post {      
        always {          
            echo 'One way or another, I have finished'          
            deleteDir() /* clean up our workspace */      
        }      
        success {          
            echo 'I succeeeded!'      
        }      
        unstable {          
            echo 'I am unstable :/'      
        }      
        failure {          
            echo 'I failed :('      
        }      
        changed {          
            echo 'Things were different before...'      
        }  
    }
}

以上是一个基本的Jenkinsfile模板，其中有以下几个关键概念

• agent - 指定在哪台机器上执行任务，还记得上面配置Node时候填的Label吗，如果这两个label匹配得上，就在该Node中执行

• stage - 组成工作流的大的步骤，这些步骤是串行的，例如build，test，deploy等

• steps - 描述stage中的小步骤，同一个stage中的steps可以并行

• sh - 执行shell命令

• input - 需要你手动点击确定，Pipeline才会进入后续环节，常用于部署环节，因为很多时候部署都需要人为的进行一些确认

• post - 所有pipeline执行完成后，会进入post环节，该环节一般做一些清理工作，同时还可以判断pipeline的执行状态。

  好了，现在要测试pipeline功能，把上面的代码中的sh换成echo，拷贝到你的Jenkinsfile中，并存放在git仓库的根目录

（1）创建pipeline

回到Jenkins web页面，添加pipeline

（2）如果你想每次git commit时自动执行该pipeline，是让Jenkins对git进行轮询，每分钟检查git仓库有没有更新，如下配置

（3）最后，我们需要设置git的地址，其中的授信设置，和上面说的Master到Node的授信设置一致

设置完毕后，一旦你的git仓库收到新的提交，就会触发这个pipeline的运行，以下这张图是上面Jenkinsfile例子的运行状态，可以看到当运行到Sanity check这一步时，需要你手动触发是否执行后面的操作。

七、附：jenkins官方文档：https://www.w3cschool.cn/jenkins/