自动化集成（二） GitLab+Jenkins实现CI/CD

1.Jenkins概述

1.1 Jenkins介绍与优势

Jenkins是一个基于Java开发的开源的、易操作的CI/CD工具软件，其主要用于持续、自动的构建/测试/部署软件项目、监控外部任务的运行。Jenkins用Java语言编写，可在Tomcat等流行的servlet容器中运行，也可独立运行（Jenkins通常作为一个独立的应用程序在其自己的流程中运行，内置Java servlet容器/应用程序服务器）。

Jenkins作为一个第三方独立的CI/CD系统，具有开源、简单、可视化web管理、跨平台部署（Windows/Linux/Docker）、功能/插件丰富等优势（注意Jenkins本身是不具备任何功能的，只提供CI/CD管理环境，Jenkins中所有的功能全部来自于插件）。另一个比较流行的CI/CD工具是GitLab Runner（可与Gitlab完美集成，此处不用耦合性高）。

1.2 CI/CD整合实现思路

（1）开发者将新版本代码 push 到 GitLab 远程仓库上；
（2）随后 GitLab 会通知 Jenkins 来进行拉取最新代码到本地（通过 Web Hook 或定时检测）；
（3）最后 Jenkins 会根据事先配置好的任务脚本执行进行Build和部署；
（4）返回结果信息给GitLab/其他Web服务器；
（5）GitLab/其他服务器发送邮件通知给开发者/测试人员，提示结果信息；

2.Jenkins服务Linux部署安装

##===== 虚拟机前置准备（已安装可忽略） =====
#（1）禁用防火墙（或开启HTTP/HTTPS）
systemctl stop firewalld
systemctl disable firewalld
#（2）开启网络
vi /etc/sysconfig/network-scripts/ifcfg-ens33
#（3）修改 ONBOOT=yes
systemctl restart network.service
#（4）安装ifconfig、wget工具
yum install -y net-tools.x86_64 #net-tools 网络工具，包含ifconfig，看ip
yum install -y wget
#（5）安装ca-certificates  HTTP连接协议安全证书
yum install -y ca-certificates
#（6）安装vim编辑器
yum install -y vim*

2.1 Java环境安装

（1）从Java官网下载 jdk8 的linux安装包（jdk-8u333-linux-x64.tar.gz），然后通过ftp上传到服务器/usr/local/java目录下

（2）解压jdk压缩包至安装目录，安装java环境

tar -zxvf jdk-8u333-linux-x64.tar.gz #解压至当前目录

（3）配置环境变量，并使配置生效

vim /etc/profile #编辑环境变量配置文件

##====末尾追加内容====##
export JAVA_HOME=/usr/local/java/jdk1.8.0_333
export JRE_HOME=${JAVA_HOME}/jre
export CLASSPATH=.:${JAVA_HOME}/lib:${JRE_HOME}/lib
export PATH=${JAVA_HOME}/bin:$PATH

source /etc/profile #生效配置
java -version #测试是否成功

2.2 Jenkins下载安装

#（1） wget -O 命令将请求url资源文件 下载到本地并重命名（请求前先关闭防火墙！！！或者打开HTTP/HTTPS端口服务）
# 该步骤请求下载远程jenkins.repo yum源仓库配置信息文件（稳定版），并下载到本地yum源配置
wget -O /etc/yum.repos.d/jenkins.repo https://pkg.jenkins.io/redhat-stable/jenkins.repo

#（2） 导入公钥，用于校验yum下载安装包是否安全合法（失败多试几次，网络较慢）
# 这个公钥是为了防止软件被黑客篡改，如果没有公钥或公钥不正确则会安装失败。可以通过修改配置文件gpgcheck=0不检测公钥安装，但是不推荐。
# jekins yum配置中gpgcheck=1，表示下载资源需要使用官方公钥校验rpm包的正确性，而该yum库中并未配置公钥信息，所以需手动导入
rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io.key

#（3） yum下载安装jenkins（默认最新版）
yum install -y jenkins

#（4） 配置jenkins信息
vim /etc/sysconfig/jenkins #编辑jenkins配置文件
JENKINS_PORT="8080" #修改jenkins监听端口（默认为8080）
JENKINS_USER="root" #修改jenkins文件权限操作用户（默认为"jenkins"）

#（5） 配置jenkins 启动信息（启动时，本地JAVA信息没有部署到jenkins），有以下两种方式：

##	- 方式一：配置jenkins初始化文件添加java路径（大多数情况下失效）
vim /etc/init.d/jenkins #编辑jenkins启动配置
#修改candidates部分增加java可选路径：/usr/java/jdk1.8.0_333/bin/java
candidates="
/etc/alternatives/java
/usr/lib/jvm/java-1.8.0/bin/java
/usr/lib/jvm/jre-1.8.0/bin/java
/usr/lib/jvm/java-11.0/bin/java
/usr/lib/jvm/jre-11.0/bin/java
/usr/lib/jvm/java-11-openjdk-amd64
/usr/bin/java
#以上是原来的，下面是新增本地的
/usr/local/java/jdk1.8.0_333/bin/java

##	- 方式二：添加软连接，为自定义java环境创建快捷方式 /usr/bin/java(有时失效，初次启动较慢，多试几次)
#也可以直接添加软连接（快捷方式） -- 
ln -s /usr/local/java/jdk1.8.0_333/bin/java /usr/bin/java

#（6） 刷新配置
systemctl daemon-reload

#（7） 启动jenkins，并配置开机启动
systemctl start jenkins
systemctl enable jenkins

#（8） 查看初始密码 
/var/lib/jenkins/secrets/initialAdminPassword

2.3 安装踩坑

出现问题 ： systemctl start jenkins 启动失败（jenkins.service: Start request repeated too quickly.）

#（1）方法一： 直接使用脚本启动jenkins（可行，猜测jenkins没法识别/激活自定义的java环境）
#进入 /etc/init.d
./jenkins start 开启jenkins
./jenkins status 查看状态
./jenkins stop 停止jenkins

#（2）方法二： https://blog.csdn.net/zwjzone/article/details/125170820

#（3）方法三： 离线安装（先下载在上传也可）--没试
wget https://pkg.jenkins.io/redhat/jenkins-2.156-1.1.noarch.rpm
rpm -ivh jenkins-2.156-1.1.noarch.rpm
#修改配置
vim /etc/sysconfig/jenkins

#（4）方法4： 官网推荐步骤安装，使用open-jdk（https://www.jenkins.io/doc/book/installing/linux/#red-hat-centos）(可行)
sudo wget -O /etc/yum.repos.d/jenkins.repo https://pkg.jenkins.io/redhat-stable/jenkins.repo
sudo rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io.key
#只升级所有本地yum包，不升级软件和系统内核，软件和内核保持原样。
sudo yum upgrade
# Add required dependencies for the jenkins package
sudo yum install java-11-openjdk
sudo yum install jenkins
sudo systemctl daemon-reload

#（5）方法5： 添加软连接配置。（可行，初次启动较慢，多试几次）
ln -s /usr/local/java/jdk1.8.0_333/bin/java /usr/bin/java

3.Gitlab自动集成实现

说明一下，Jenkins与Gitlab的交互包括两部分：

• 一部分是Gitlab通过Webhook提交Git Push事件，触发Jenkins开始执行集成任务。
• 一部分是Jenkins配置集成任务，通过Git从Gitlab拉取源代码并执行编译/发布脚本。

3.1 Jenkins服务配置

（1）选择推荐插件安装（自动安装一些基础插件，等待5-10分钟），更新下载和更新源为国内源

# 选择推荐插件安装（自动安装一些基础插件，等待5-10分钟）,更新下载和更新源为国内源：
- 第一步，修改插件更新中心地址：在Jenkins页面，进入Manage Jenkins–>Manage Pkugin—>Advanced 最下面有Update Site，设置为 https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json（清华镜像）。该步骤会在centos服务器上，自动执行vim /var/lib/jenkins/hudson.model.UpdateCenter.xml，修改url为https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json
- 第二步，修改插件默认下载地址：vim /var/lib/jenkins/updates/default.json，将其中的  updates.jenkins-ci.org/download 替换为 mirrors.tuna.tsinghua.edu.cn/jenkins ，然后把www.google.com 修改为 www.baidu.com 
- 第三步，重启jenkins服务，刷新浏览器OK  'systemctl restart jenkins'

（2）添加/创建管理员+配置URL，完成后进入Jenkins主页

（3） 安装Jenkin相关插件

# 安装Jenkin相关插件
# 作用：在Jenkins中辅助相关功能的实现，插件的实现一般还需要调用并配合本地程序，并在全局配置中声明本地程序信息，让插件知道本地程序在哪。
Credentials						   # 签名证书管理插件
Gitlab							   # 安装后从 GitLab 获取代码
Git	和 Git Client				   # 用于 Jenkins 在 GitLab 中拉取源码
Generic Webhook Trigger			   #GitLab 触发 Jenkins 构建项目, Gitlab Hook这个插件被代替了
Gitlab Authentication			   # GitLab 和 Jenkins 认证插件
SSH Plugin						   # 进程执行 Shell 脚本
Publish Over SSH				   # 用于通过 SSH 部署应用

3.2 Jenkins全局环境设置

• 设置位置： 设置 - Global Tool Configuration - 配置：其实际的操作过程相当于配置全局的环境变量，以便Jenkins能够通过对应插件调用该工具，然后进行本地操作。
• 插件作用： 在Jenkins中辅助相关功能的实现，插件的实现还需要调用并配合本地程序，因此本地也需要安装相关程序，并在Jenkins中配置信息（也可以在Jenkins中配置自动安装）。比如Git插件：git插件为Jenkins项目提供基本的git交互操作。它可以轮询、获取、签出、分支、列表、合并、标记和推送存储库。

（1）Java全局环境设置

（2）Git全局环境设置

## 1.安装git示例：
#	- 自动安装： yum install -y git #centos 默认的git版本为1.8（但目前最新的git版本已经到了2.3，不推荐）
#	- 源码安装：
#		- 如果存在已安装老版本git，先卸载：yum remove -y git
#		- 下载最新版的tar.gz安装包（不要选择rc/最新版）,链接https://github.com/git/git/tags：
#			- wget https://github.com/git/git/archive/refs/tags/v2.36.0.tar.gz
#			- 下载至本地，然后通过ftp上传至虚拟机：/usr/local/src下
#		- 安装git环境依赖：
yum install curl-devel expat-devel gettext-devel openssl-devel zlib-devel gcc perl-ExtUtils-MakeMaker
#		- 解压git安装包到当前文件夹下
tar xzvf v.36.0.tar.gz
#		- 进入解压后的目录
cd /usr/local/src/git-2.36.0
#		- 执行源码编译安装 make && make install (必须在当前源码目录下)
make prefix=/usr/local/git all #等价于make，它从Makefile中读取编译指令，进行源代码编译
make prefix=/usr/local/git install #编译后程序安装到指定目录prefix
#		- 添加环境变量
vim /etc/profile
export PATH="xxx:/usr/local/git/bin:$PATH"
source /etc/profile
#		- 配置全局suer
git config --global user.name xxx
git config --global user.email 182xxxxxxxx@163.com
git config --list #查看全局配置
git --version

## 2.jenkins全局配置git路径

注意： 这里的git位置必须是可执行文件的地址，即是git/bin/下的可执行文件 git的目录地址！不配置git本地程序的话，无法创建执行任务，拉取程序到本地管理。

3.3 自动拉取及部署任务构建

注意： 除了ssh免密的方式，也可以在jenkins添加 UserName and Password 的全局凭证（用户名和登录密码），来实现自动拉取 ，这里仅以ssh免密拉取为例。
（1）配置 Jenkins 免密拉取

# 配置 Jenkins 免密拉取
ssh-keygen -t rsa #jenkins服务器生成ssh密钥
cat .ssh/id_rsa.pub #公钥上传到gitlab
cat .shh/id_rsa #私钥上传至jenkins

• 公钥配置： 这里直接使用的Gitlab root管理员，意味着通过这个SSH密钥对验证成功后，Jenkins可以拉取所有项目的代码
  

• 私钥配置： Jenkins 的 root 用户公钥在 GitLab 上，私钥在 Jenkins 上，目的就是为了方便 Jenkins 可以直接免密拉去 GitLab 上的代码。
  
  

（2）Jenkins 新建任务配置

Jenkins 新建任务Item => Freestyle project => 配置任务信息

• General选项卡： 配置任务描述、自定义源码数据工作目录等任务基本信息
  

- 描述： 任务描述信息
- Discard old builds：构建生成记录（Build History）的丢弃规则。如过期天数、最大记录个数等。默认不过期
- 使用自定义的工作空间：自定义工作目录，默认/var/lib/jenkins/workspace/xx
- This project is parameterized:配置Job全局 key-value参数。该参数可在构建时使用Build With Parameters，或者作为Job环境变量，或者在配置中做变量替换，或者在脚本执行中，通过${参数的名称}使用创建的参数。
- Throttle builds：配置允许用户触发的构建过程的速率/频率限制，单位有时、天、周、月、年。
- 关闭构建： 禁用这个build任务，例如，如果您的项目依赖于某些基础结构（例如测试服务器或源代码存储库），并且您知道它将在一段时间内不可用，则可以禁用该项目以防止在此期间出现不必要的生成失败
- 在必要的时候并发构建： 选中此选项后，可以并行执行此项目的多个生成。默认情况下，一次只执行一个项目的单个生成-开始生成该项目的任何其他请求都将保留在生成队列中，直到第一个生成完成。

• 源码管理选项： 该选项用于配置源码库链接信息，通常根据引入插件来选择不同的源码仓库。此处以Git为主，配置源码管理后，首次Build会自动从源码仓库Clone代码到本地，后面的每次Build都会pull更新本地代码。
  

- 源码库浏览器：这个配置功能的作用是在任务执行后，如果代码发生变更change，会在构建任务的界面会新增一个连接，能够跳转到该[中心仓库的变更说明页面]。URL--仓库web地址；Version--gitlab服务器版本
- Additional Behaviours：配置额外的源码拉取行为，比如时间限制、大小限制、文件拆分、前置后置代码检查等

• 构建触发器选项： 该选项用于配置 什么时间/什么条件 下会自动触发我们配置的该Build Job，即触发策略。

- 触发远程构建 (例如,使用脚本)：配置通过访问特殊的预定义URL（便于脚本）触发Build，可以在代码层面触发构建。此功能的一个典型示例是，当某人刚刚将更改提交到存储库时，从源代码管理系统的挂钩脚本触发新构建。您需要以字符串的形式提供授权令牌，以便只有知道它的人才能远程触发此项目的构建。
- Build after other projects are built：其他项目完成构建时，触发Build。例如，这便于在其他上游/前置项目构建完成后运行测试项目。
- Build periodically：通过cron语法，定期执行此项目Build
- Build when a change is pushed to GitLab. GitLab webhook URL:主要用于Jenkins与GitLab相结合，在提交Push代码到GitLab后，触发WebHook构建。 
- Generic Webhook Trigger:启用Generic Webhook Trigger触发Build

• 构建环境选项： 构建环境就是构建之前的一些准备工作，如指定构建工具、执行方式等。

- Execute shell script on remote host using ssh：您可以在构建之前和之后远程执行shell脚本（ssh）
- Delete workspace before build starts：构建执行之前，清空相关的workspace
...

• 构建选项： 拉去更新代码后，自动执行Build程序

- Execute Windows batch command：运行Windows批处理脚本
- Execute shell： 运行shell脚本（默认为sh，但这是可配置的）***主要***
...

• 构建后的操作选项： 做一些构建任务完成之后的操作，比如

  • 构建其他项目 Build other projects
  • 邮件通知 E-mail Notification
  • Gitlab状态推送等 Git publisher

（3）执行构建Build，自动拉取远程仓库代码

• 任务详情： 点击进入该任务详情，可以查看历史构建记录，进入控制台输出日志
  
• 数据存储： Jenkins使用Git源码管理拉取下来的代码存放位置在： /var/lib/jenkins/workspace/任务名称/下
  

（4）构建执行脚本，简单输出信息测试

• 在Jenkins服务器编写 /usr/local/scripts/gitlab_job.sh 脚本如下：

#!/bin/bash
# #!/bin/bash表示 此脚本只能用/bin/bash来解释执行，#!是一个特殊标识符后跟解释此脚本的shell路径。bash只是shell的一种，其他还有sj、csh等其他shell
# #!/bin/bash只能放在第一行，如果后面还有则只会看成注释

echo "gitlab_job 脚本执行..."
cat /var/lib/jenkins/workspace/Jenkins_AutoClone/test.txt

• 在构建任务中，选择Execute shell执行脚本，配置脚本执行信息
  
• 更新仓库代码后，执行任务Build Now查看执行结果。可以看到任务在自动更新拉取仓库代码后，执行了Build脚本：
  

（5）可进一步将拉取的代码发布到其他Web服务器编译/部署（需配置两台机器免密交互）

- 在 GitLab 上创建（上传）项目后，然后 Jenkins 会将代码自动拉取下载到本地；
- 在使用 Jenkins 将代码在拉取完成后，将项目发送给指定Web服务器进行编译/打包/发布；

注意： 以上方式目前都只是手动拉取和执行，我们需要继续在Gitlab中配置更新触发Jenkins拉取的Hook，在Gitlab更新代码时自动触发Jenkins的任务。

3.4 Hook配置触发Jenkins

（1）Jenkins webHook 配置

• 基本配置信息： 配置触发Build的事件

• Push Events ：Push事件
• Opened Merge Request Events：合并事件
• Comments：评论事件
• …其他配置信息

• 拓展配置信息： 触发分支与Token

Jenkins webHook可以指定触发分支：可以指定特定分支触发WebHook接口。Jenkins和Gitlab可以分别配置触发分支信息，Gitlab配置分支信息即只有特定分支发生change相应的事件才会发送请求到WebHook URL接口（但Jenkins不一定会接受）；Jenkins配置分支信息即接收的触发请求只有特定分支下的才会触发Build任务（Gitlab不到一定发送）。

（2）Gitlab webHook配置

• Gitlab 本地网络请求配置

​ GitLab 10.6 版本以后为了安全，不允许向本地网络发送 WebHook 请求。在Gitlab - 管理员配置 - 设置 - 网络 - 出站请求/外发请求 中进行本地网络配置。

• Gitlab 相关项目中 设置webHook集成配置

• 网站URL ： Jenkins配置的Hook 触发url，gitlab发生相应的事件后会向该Hook Url发送请求，以触发Jenkins构建任务
• 秘密令牌： Jenkins配置的访问Token令牌，只有携带该令牌才会正确触发URL，以增大安全性
• 推送事件：如果不填写，则任何分支的Push事件均可触发该WebHook，发送触发请求；填写分支名称后，只有该分支上的Push事件才会触发WebHook请求。
• 其他事件：…

​ 若配置成功，则会显示如下webHook 站点（查看编辑，下方会显示该WebHook接口的请求访问信息）如下：

（3）测试连通

​ 测试站点 Push events：显示Hook successful: HTTP 200 ;同时，Jenkins服务器中也会显示相应的 Build 信息输出。

3.4 WebHook执行原理

重点就是这个WebHook URL是什么： 可以将它看作是一个接口，用来监听处理gitlab的事件。

（1）项目代码变动往gitlab上推送相应的事件，例如代码push，新建tag，创建merge request等等；

（2）gitlab收到相应事件，触发对应的webhook，设置HTTP请求的header以及request body，然后发送HTTP请求到配置的webhook的URL；

（3）HTTP请求到达对应的处理服务器以后，对request body和header进行解析，包装通知内容；

（4）将通知的内容通过企业微信的消息发送接口发送到企业微信/邮箱/钉钉；

4.返回结果通知

​ 在Jenkins构建Build任务完成之后，需要将测试/执行结果主动返回给测试人员（测试人员和运维各司其职），我们这里选择邮件通知的方式（以QQ邮箱为例，其他邮件大同小异）。

• Jenkins自带的邮件通知功能：比较简单，无法自定义格式和详细内容信息，每次自动发送构建的输出信息
• Jenkins邮件拓展插件：提供更加灵活的格式、发送方式等（我们这里项目实践以此为例）

4.1 Jenkins自带的邮件通知服务

​ Jenkins自带的邮件通知功能比较简单，无法自定义邮件格式和详细内容等信息，每次自动发送的邮件内容是构建的输出信息日志。

4.1.1 通知邮箱基本配置

（1）开启邮箱SMTP服务

​ SMTP（Simple Mail Transfer Protocol，邮件传输协议）是一种提供可靠且有效的电子邮件传输的协议，开启邮箱的SMTP服务可用于将邮件从一台服务器推送到另一台服务器。SMTP包括 POP3和IMAP，都是一种邮件获取协议，区别为IMAP是双向的。

• 打开QQ邮箱 - 设置 - 账户 -开启IMAP/SMTP服务
  
• 生成授权码，用于邮件推送服务认证
  

（2）QQ邮箱常用配置信息

4.1.2 Jenkins 邮件通知基本配置

（1）邮箱推送信息全局配置

• 进入 管理 - Configure System - 配置全局管理员邮箱（必需）
  
  

• Jenkins 基本邮件通知服务配置 - 邮件通知
  
  测试邮件服务是否正常（收到测试邮件）：
  
  

（2）邮箱推送信息项目配置

• 配置Job信息 - 构建后操作 - 添加构建后操作步骤 - 选择 E-mail Notification
  

• 配置基本的邮件通知任务
  

• 测试结果
  ​ Build Success时是不会出发邮件通知的，只有构建失败/构建失败后的首次构建成功/不稳定构建时才会发送通知。我们通过让脚本执行一个不存在的文件来使任务构建失败，然后查看邮件通知效果如下（默认邮件通知模板）：
  
  

4.2 拓展插件配置

注意：拓展插件的工作必须配置全局管理员邮箱信息，且管理员邮箱和发送邮件的邮箱必须一致。但是拓展插件独立于Jenkins自带的邮箱配置，可以不用配置4.1的全局基本邮件通知配置。

4.2.1 Jenkins 安装 Email 拓展插件

• Email Extension Plugin ： 这个插件取代了Jenkins自带的电子邮件发布。它允许配置/定制电子邮件通知的各个方面，比如电子邮件发送者/接收者/发送方式/发送内容等
• Email Extension Template： 这个插件用于帮助用户方便的定制邮件内容格式（该插件用于插件拓展的邮件通知服务）

4.2.2 Extendend E-mail Notification 全局配置

​ 进入 管理 - Configure System - Extendend E-mail Notification 配置邮箱拓展插件。

 Default Content Type：指定构建后发送邮件内容的类型，有Text和HTML两种。
 Use List-ID Email Header：为所有的邮件设置一个List-ID的邮件信头。
 Add 'Precedence: bulk' Email Header：设置优先级。
 Default Recipients：自定义默认电子邮件收件人列表。
 Reply To List：回复列表。
 Emergency reroute：如果这个字段不为空，所有的电子邮件将被单独发送到该地址（或地址列表）。
 Excluded Committers：防止邮件被邮件系统认为是垃圾邮件，邮件列表应该没有扩展的账户名(如:@domain.com)，并且使用逗号分隔。
 Default Subject：自定义邮件通知的默认主题名称。该选项能在邮件的主题字段中替换一些参数，这样就可以在构建中包含指定的输出信息。
 Maximum Attachment Size：邮件最大附件大小。
 Default Content：自定义邮件通知的默认内容主体。该选项能在邮件的内容中替换一些参数，这样就可以在构建中包含指定的输出信息。
 Default Pre-send Script：默认发送前执行的脚本。
 Enable Debug Mode：启用插件的调试模式。
 nable Security：启用时，会禁用发送脚本的能力，直接进入Jenkins实例。如果用户试图访问Jenkins管理对象实例，将抛出一个安全异常。
 Content Token Reference：邮件中可以使用的变量，所有的变量都是可选的。

• 配置邮箱服务器基本信息
  

• 配置邮件内容格式
  
  
  

4.2.3 构建任务配置

​ 构建任务设置 - 构建后操作 - 添加构建后操作步骤 - Editable Email Notification，配置如下：

4.2.4 Jenkins 常见内置环境变量

(187条消息) Jenkins 常用变量_运维生涯记录的博客-CSDN博客_jenkins系统变量

Jenkins内置环境变量的使用 - 贺满 - 博客园 (cnblogs.com)

1.WORKSPACE：当前Job构建目录的绝对路径；
2.SVN_REVISION：当前工作区的Subversion版本号；
3.SVN_URL：当前工作区的Svn URL；
4.BUILD_NUMBER：当前构建的编号，例如“4674”等；
5.BUILD_ID：当前构建的版本ID，与构建的BUILD_NUMBER相同；
6.BUILD_DISPLAY_NAME：当前版本的显示名称，默认为“# 4674”，即BUILD_NUMBER；
7.JOB_NAME：即此版本的项目名称，例如“foo”或“foo / bar”；
8.JENKINS_HOME：Jenkins用于存储数据的主节点上分配的目录的绝对路径；
9.JENKINS_URL：Jenkins的完整URL，如http：// server：port / jenkins /（注意：仅在系统配置中设置Jenkins URL时可用）；
10.BUILD_URL：此版本的完整URL，例如http：// server：port / jenkins / job / foo / 15 /（必须设置Jenkins URL）；
11.JOB_URL：该作业的完整URL，例如http：// server：port / jenkins / job / foo /（必须设置Jenkins URL）；
12.BRANCH_NAME：对于多分支项目，这将被设置为正在构建的分支的名称，例如，如果您希望从master部署到生产环境而不是从feature分支部署；如果对应某种更改请求，则该名称通常是任意的（请参阅下面的CHANGE_ID和CHANGE_TARGET）；
13.CHANGE_ID：对于与某种更改请求相对应的多分支项目，这将被设置为更改ID，例如拉取请求编号（如果支持）;其他未设置；
14.CHANGE_URL：对于与某种更改请求相对应的多分支项目，这将被设置为更改URL(如果支持)；其他未设置；
15.CHANGE_TITLE：对于与某种更改请求相对应的多分支项目，这将被设置为更改的标题（如果支持）;其他未设置；
16.CHANGE_AUTHOR：对于与某种更改请求相对应的多分支项目，这将被设置为建议更改的作者的用户名（如果支持）;其他未设置；
17.CHANGE_AUTHOR_DISPLAY_NAME：对于与某种更改请求相对应的多分支项目，这将被设置为建议更改的作者的人名（如果支持）;其他未设置；
18.CHANGE_AUTHOR_EMAIL：对于与某种更改请求相对应的多分支项目，这将被设置为建议更改的作者的Email地址（如果支持）;其他未设置；
19.CHANGE_TARGET：对于与某种更改请求相对应的多分支项目，这将被设置为合并到的目标或者基础分支（如果支持）;其他未设置；
20.JOB_BASE_NAME：此构建的项目的短名称剥离文件夹路径，例如“bar / foo”的“foo”；
21.BUILD_TAG：“jenkins - $ {JOB_NAME} - $ {BUILD_NUMBER}”的字符串。 JOB_NAME中的所有正斜杠（/）都用破折号（ - ）替换。方便地放入资源文件，jar文件等，以便于识别。
22.EXECUTOR_NUMBER：唯一编号，用于标识执行此构建的当前执行程序（在同一台计算机的执行程序中）。这是您在“构建执行程序状态”中看到的数字，但数字从0开始，而不是从1开始。
23.NODE_NAME：如果构建在代理上，则代理的名称; 如果在主版本上运行，则为“MASTER”；
24.NODE_LABELS：节点分配的空白分隔的标签列表。
25.GIT_COMMIT：The commit hash being checked out；
26.GIT_PREVIOUS_COMMIT：The hash of the commit last built on this branch, if any；
27.GIT_PREVIOUS_SUCCESSFUL_COMMIT：The hash of the commit last successfully built on this branch, if any；
28.GIT_BRANCH：远程分支名称，如果有的话；
29.GIT_LOCAL_BRANCH：本地分支名称，如果有的话；
30.GIT_URL：远程git仓库的URL。如果有多个，将会是GIT_URL_1，GIT_URL_2等；
31.GIT_COMMITTER_NAME：配置的Git提交者名称（如果有的话）；
32.GIT_AUTHOR_NAME：配置的Git作者姓名（如果有的话）；
33.GIT_COMMITTER_EMAIL：配置的Git提交者电子邮件（如果有的话）；
34.GIT_AUTHOR_EMAIL：已配置的Git作者电子邮件（如果有）；
35.JOB_DESCRIPTION：显示项目描述；
36.CAUSE： 显示谁、通过什么渠道触发这次构建；
37.CHANGES：显示上一次构建之后的变化；
showPaths 如果为 true,显示提交修改后的地址。默认false。
showDependencies 如果为true，显示项目构建依赖。默认为false
format 遍历提交信息，一个包含%X的字符串，其中%a表示作者，%d表示日期，%m表示消息，%p表示路径，%r表示版本。注意，并不是所有的版本系统都支持%d和%r。如果指定showPaths将被忽略。默认“[%a] %m\\n”。
pathFormat 一个包含“%p”的字符串，用来标示怎么打印路径。

38.PROJECT_NAME：显示项目的全名
39.PROJECT_DISPLAY_NAME：显示项目的显示名称。（见AbstractProject.getDisplayName）
40.SCRIPT：从一个脚本生成自定义消息内容。自定义脚本应该放在"$JENKINS_HOME/email-templates"。当使用自定义脚本时会默认搜索$JENKINS_HOME/email-templatesdirectory目录。其他的目录将不会被搜索。
script 当其使用的时候，仅仅只有最后一个值会被脚本使用（不能同时使用script和template）。
template常规的simpletemplateengine格式模板。
41.BUILD_LOG_MULTILINE_REGEX：按正则表达式匹配并显示构建日志。
regex java.util.regex.Pattern 生成正则表达式匹配的构建日志。无默认值，可为空。
maxMatches 匹配的最大数量。如果为0，将匹配所有。默认为0。
showTruncatedLines 如果为true，包含[...truncated ### lines...]行。默认为true。
substText 如果非空，就把这部分文字（而不是整行）插入该邮件。默认为空。
escapeHtml 如果为true，格式化HTML。默认为false。
matchedSegmentHtmlStyle 如果非空，输出HTML。匹配的行数将变为<b style=”your-style-value”> html escaped matched line </b>格式。默认为空。
42. BUILD_LOG：显示最终构建日志。
maxLines 日志最多显示的行数，默认250行。
escapeHtml 如果为true，格式化HTML。默认false。
43.PROJECT_URL：显示项目的URL地址。
44.BUILD_STATUS：显示当前构建的状态(失败、成功等等)
45.BUILD_URL：显示当前构建的URL地址。
46.CHANGES_SINCE_LAST_SUCCESS：显示上一次成功构建之后的变化。
reverse在顶部标示新近的构建。默认false。
format遍历构建信息，一个包含%X的字符串，其中%c为所有的改变，%n为构建编号。默认”Changes for Build #%n\n%c\n”。
showPaths,changesFormat,pathFormat分别定义如${CHANGES}的showPaths、format和pathFormat参数。
47.CHANGES_SINCE_LAST_UNSTABLE：显示显示上一次不稳固或者成功的构建之后的变化。
reverse在顶部标示新近的构建。默认false。
format遍历构建信息，一个包含%X的字符串，其中%c为所有的改变，%n为构建编号。默认”Changes for Build #%n\n%c\n”。
showPaths,changesFormat,pathFormat分别定义如${CHANGES}的showPaths、format和pathFormat参数。
48.ENV：显示一个环境变量。
var– 显示该环境变量的名称。如果为空，显示所有，默认为空。
49.FAILED_TESTS：如果有失败的测试，显示这些失败的单元测试信息。
50.HUDSON_URL：不推荐，请使用$JENKINS_URL
51.JELLY_SCRIPT：从一个Jelly脚本模板中自定义消息内容。有两种模板可供配置：HTML和TEXT。你可以在$JENKINS_HOME/email-templates下自定义替换它。当使用自动义模板时，”template”参数的名称不包含“.jelly”。
template模板名称，默认”html”。
52.TEST_COUNTS：显示测试的数量。
var– 默认“total”。
total -所有测试的数量。
fail -失败测试的数量。
skip -跳过测试的数量。

4.2.5 Jenkins 常见邮件内容模板

<!DOCTYPE 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">
    <table width="95%" cellpadding="0" cellspacing="0"
        style="font-size: 11pt; font-family: Tahoma, Arial, Helvetica, sans-serif">
        <tr>
            <td>
                <h2>
                    <font>来自Mr.Jenkins的邮件通知</font>
                </h2>
            </td>
        </tr>
        <tr>
            <td>
                <br />
                <b><font color="#0B610B">构建信息</font></b>
               <hr size="2" width="100%" align="center" />
             </td>
        </tr>
        <tr>
            <td>
                <ul>
                    <li>项目名称 ： ${PROJECT_NAME}</li>
                    <li>触发原因 ：${CAUSE}</li>
                    <li>构建日志 ： <a href="${BUILD_URL}console">${BUILD_URL}console</a></li>
                    <li>单元测试报告 ：<a href="${BUILD_URL}testReport/">${BUILD_URL}testReport/</a></li>
                    <li>工作目录 ： <a href="${PROJECT_URL}ws">${PROJECT_URL}ws</a></li>

                </ul>
            </td>
        </tr>
                <tr>
            <td><b><font color="#0B610B">构建日志:</font></b>
            <hr size="2" width="100%" align="center" /></td>
        </tr>
        <tr>
            <td><textarea cols="80" rows="30" readonly="readonly"
                    style="font-family: Courier New">${BUILD_LOG}</textarea>
            </td>
        </tr>
    </table>
</body>
</html>

<!DOCTYPE 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">
    <table width="95%" cellpadding="0" cellspacing="0"  style="font-size: 11pt; font-family: Tahoma, Arial, Helvetica, sans-serif">
        <tr>本邮件由系统自动发出，无需回复！
            <br/>各位同事，大家好，以下为${PROJECT_NAME }项目构建信息</br>
            <td><font color="#CC0000">构建结果 - ${BUILD_STATUS}</font></td>
        </tr>
        <tr>
            <td><br />
            <b><font color="#0B610B">构建信息</font></b>
            <hr size="2" width="100%" align="center" /></td>
        </tr>
        <tr>
            <td>
                <ul>
                    <li>项目名称： ${PROJECT_NAME}</li>
                    <li>构建编号： 第${BUILD_NUMBER}次构建</li>
                    <li>触发原因： ${CAUSE}</li>
                    <li>构建状态： ${BUILD_STATUS}</li>
                    <li>项目URL： <a href="${PROJECT_URL}">${PROJECT_URL}</a></li>
                    <li>工作目录： <a href="${PROJECT_URL}ws">${PROJECT_URL}ws</a></li>
                    <li>构建URL： <a href="${BUILD_URL}">${BUILD_URL}</a></li>
                    <li>构建日志： <a href="${BUILD_URL}console">${BUILD_URL}console</a></li>
                    <li>测试报告： <a href="${BUILD_URL}HTML_20Report/">${BUILD_URL}HTML_20Report/</a></li>
                </ul>
                <h4><font color="#0B610B">失败用例</font></h4>
                <hr size="2" width="100%" />$FAILED_TESTS<br/>
                <h4><font color="#0B610B">最近提交版本(git：$GIT_REVISION)</font></h4>
                <hr size="2" width="100%" />
                <ul>
                ${CHANGES_SINCE_LAST_SUCCESS, reverse=true, format="%c", changesFormat="<li>%d[%a] %m</li>"}
                </ul>
                    详细提交: <a href="${PROJECT_URL}changes">${PROJECT_URL}changes</a><br/>
            </td>
        </tr>
    </table>
</body>
</html>

5.Windows下安装配置Jenkins服务（补充）

5.1 环境准备

（1）jdk安装配置

​ jdk的安装配置相比linux来说要简单得多，直接在官网下载windows安装包（ jdk8下载），然后安装并配置环境变量即可。

（2）git安装配置

​ git的安装配置相比linux来说要简单得多，直接在官网下载安装程序无脑安装下一步即可。

5.2 Jenkins安装

​ 直接在官网下载Jenkins安装程序 Jenkins download and deployment（LTS，稳定版），然后双击安装程序安装即可。访问 http://localhost:8888

​ 其他操作与Linux上的大同小异，别忘了配置全局git、jdk等以及插件安装。

5.3 自定义Jenkins目录配置

（1）插件更新和下载源配置

• 修改插件默认下载地址：C:\ProgramData\Jenkins.jenkins\updates\default.json 修改url同linux
• 修改插件更新中心地址：在Jenkins 配置页面修改镜像同linux

（2）工作目录配置

(187条消息) jenkins：windows环境下详细安装步骤，并解决windows版本下配置信息默认安装路径问题_Hello，Mr.S的博客-CSDN博客_jenkins windows

注意： Jenkins默认主目录配置文件在 C:\ProgramData\Jenkins\ .jenkins，Jenkins储存所有的数据文件在这个目录下。

6.自动编译执行

​ 此处以 VS2019 C#项目为例，使用Windows Server部署（Linux上.Net平台搭建较为困难）。执行目标为：将Gitlab上clone下来的项目代码执行编译测试，并将编译结果通过邮件返回给开发者。本地编译配置：

• 开发工具 VS2019 ，工具集 v142
• NuGet包管理器 nuget.exe v6.1.0

（1）安装NuGet：

​ Nuget是一个.NET平台下的开源的项目，它是Visual Studio的扩展。NuGet 是免费、开源的包管理开发工具，专注于在 .NET 应用开发过程中，帮助开发者简单地合并/管理第三方的组件库。比如帮助我们在项目开发中简单的引入、升级、删除、管理用到的第三方库和配置文件。官网下载目标为nuget.exe ： NuGet Gallery | Downloads 。常用命令如下：

nuget restore <projectPath> [options] #包还原命令。自动下载并安装文件夹中缺少 packages 的任何依赖包。其中 <projectPath> 指定解决方案或 packages.config 文件的位置。

（2）Jenkins安装 MSBuild 插件，配置全局MSBuild执行路径

​ MSBuild（Microsoft Build Engine），是一个 Microsoft 和 Visual Studio的应用构建生成平台。Visual Studio 在构建项目时会自动使用 MSBuild 生成，使用 MSBuild 来加载和生成托管项目；但 MSBuild 的使用不依赖于 Visual Studio。MSBuild 引入了一种新的基于 XML 的项目文件生成格式， Visual Studio 中的项目文件（.sln、.csproj、.vbproj、vcxproj 等）包含 MSBuild XML 代码，当你生成项目时，此代码就会运行。注意 MSBuild 编译后生成的是.exe 可执行文件，但却不能生成.msi 安装包文件。如果想要使用MSBuild 生成安装包文件，还需要借助WiX编辑一个wxs类型的工程。简单来说，一句话总结MSBuild的作用即利用XML配置信息对项目文件实施特定顺序的操作，实现项目生成/编译等工作。

​ 一般本机安装了VS之后，在安装目录下都会自带MSBuild。在Jenkins中需要安装MSBuild插件，并在全局配置中配置MSBuild的本地程序路径。

（3）配置Jenkins任务构建步骤 Execute Windows batch command

​ 对于一个新的仓库，首先需要还原项目所有安装的 Nuget 第三方包（安装依赖包），在Windows bach中使用nuget restore 还原命令。

（4）配置Jenkins任务构建步骤 Build a Visual Studio project or solution using MSBuild

​ 使用MSBuild 配置参数并生成/编译指定项目（更多编译参数可以自己查阅）

（5）结果

7.自动化集成方案示例

现有项目生命周期迭代开发方案如下：
（1）构建维护两种分支，分别为特性分支feat-*和开发分支development：

• development ：总开发分支，目标分支。合并所有开发功能的稳定开发版本
• feat-* ： 特性分支，功能开发分支

（2）开发人员在feat-*分支上进行单独功能的迭代开发，此时Push推送无需触发自动化构建
（2）特性分支feat-*功能开发完成后，则发起Merge Request到development，并触发Jenkins自动编译构建feat-*进行代码编译检查
（3）最终将构建结果邮件通知开发和管理人员：

• SUCCESS:则管理人员上线进行Merge Request代码Review，手动合并MR，并自动对合并后的development分支结果进行拉取、构建编译
• FAILURE:则管理人员无需关注，由开发人员回去修改代码并重新提交MR

7.1 Gitlab-plugin 插件拓展说明

​ 该插件允许GitLab在提交代码或打开/更新合并请求时触发Jenkins中的构建，它还可以将构建状态发送回GitLab。简而言之，该插件用于实现Gitlab与Jenkins交互的本地功能。详情：GitLab | Jenkins plugin

（1）提供WebHook

（2）解析Gitlab请求参数

​ 以下为Gitlab插件的内置环境变量，用于自动从Gitlab交互请求中解析和获取，这些变量可以用于作业配置的任意位置。 ${gitlabBranch}

gitlabBranch #gitlab运行分支名称
gitlabSourceBranch #gitlab请求源分支
gitlabTargetBranch #gitlab请求目标分支
gitlabActionType
gitlabUserName
gitlabUserUsername
gitlabUserEmail
gitlabSourceRepoHomepage
gitlabSourceRepoName
gitlabSourceNamespace
gitlabSourceRepoURL

7.2 需求实现

7.2.1 特性分支配置

（1）动态跟踪请求分支

​ 通过Gitlab插件可知，其内置的 ${gitlabSourceBranch} 变量可以指示请求的源分支，于是我们使用此变量来动态拉取特性分支。

（2）配置触发器WebHook

• 触发事件： 根据需求可知，特性分支feat-*只需要监控 opened MR即创建新的合并分支事件即可，而不需要关注Push事件或其他请求。
  

• 过滤分支： 并不是远端任意的opened MR事件都需要触发构建，我们需要对Merge Request的源分支和目标分支进行限制，即该Build触发必须是在feat-* => development 分支上的MR请求基础上，其他分支上的无需关注（使用正则表达式）。

源分支：Gitlab交互请求中的Source Branch，也就是Merge Request的源请求
目标分支：Gitlab交互请求中的Target Branch，也就是Merge Request的目标请求

7.2.2 开发分支配置

（1）配置触发器WebHook

• Push Events：所有的Push事件，包括Merge Request合并时也会进行Push
• Accepted Merge Request Events ：当Approved Merge Request 且 管理员合并完成后会触发 Accepted MR事件，此时也会触发Push事件（合并也会进行Push）
• Approved Merge Request Events： 当管理员进行代码Review后，点击Approved时会触发

为了避免触发两次Build，我们只勾选Push Events即可，在MR接受并合并完成后会触发development分支的Push事件，进行合并后的代码编译构建。