本研究报告参考《Jenkins2.x实践指南》。

1.Jenkins简介#

Jenkins是一个自动化的任务执行工具。通常用于持续集成/持续交付领域。

你可以通过接口或者Jenkinsfile告诉Jenkins要执行什么任务，什么时候执行。理论上，我们可以让它执行任何任务，但它通常只用于持续集成和持续交付。

持续集成将软件生产过程从手工模式带到流水线模式，软件生产的某个环节对应流水线上的每一个环节。

流水线模式还可以帮助我们把知识固化到汽车生产线上，一定程度上解决知识被人带走的问题。(手动模式很少被整个软件制作过程完全知晓，使用流水线模式的整个软件制作过程都以pipelineascode的形式保存下来，每个人都可以看到。)

2.pipeline介绍#

什么是pipeline#

学术讲座：软件从代码版本库到用户的过程的自动表达；一般来说，主要是指代码的自动构建、测试、打包、部署的过程；Jenkins1.x只能& quot描述& quot通过接口手动部署管道。Jenkins2.x终于支持pipelineascode，部署管道可以用& quot代码& quot。

更好的版本控制：将管道提交到软件版本库进行版本控制。更好的协作：每个人都可以看到管道的每个修改。另外，还可以复习一下pipeline的代码。更好的复用性：手工操作不能复用，但是代码可以复用。

什么是JenkinsFile#

Jenkinsfile是一个文本文件，是Jenkins中部署管道概念的表达。就像Dockerfile之于Docker。部署管道的所有逻辑都是用Jenkinsfile编写的。

JKFile定义了管道的部署逻辑。

Jenkins默认不支持管道，所以需要安装管道插件。

pipeline语法的支持#

管道支持以下两种语法：

Groovy文法(以node为根节点的脚本化文法)；声明式语法(2.5版本支持，以管道为根节点，推荐)

3.pipeline语法#

Groovy语法#

Groovy语法在这里不是重点，但还是需要了解必要的知识。如果想了解更多，可以参考Groovy教程。

//一般用def定义变量。//语句末尾没有添加分号defx=' ABS'Groovy中的方法调用可以省略括号printlnxprintln'chensongxia'//支持命名参数defm1(StringgivenName，String family name){ Return given name ' ' family name }//可以这样调用：printlnm1('陈'' songxia ')=M1 family name=' ru 'GivenName='赵' printlns1//支持默认参数def m2(String name=' hi '){ Return name }//括号不能省略printlnm2()printlnm2('陈')//支持单引号和双引号双引号支持插值，单引号不支持println' -单引号和双引号都支持。双引号支持插值，单引号不支持-' println ' ' defname=' world 'println ' hello $ { name } ' println ' hello $ { name } '//支持三个引号。三个引号分为三个单引号和三个双引号。都支持换行符，但是只有三个双引号支持插值。println ' ' println '-支持三个引号。三个引号分为三个单引号和三个双引号。都支持换行符，但是只有三个双引号支持插值。-' Println ' ' ' line oneline two line three $ { name } ' ' Println ' ' line oneline two line three $ { name } ' '//支持闭包println' -支持闭包' def代码。//闭包可以作为参数传递给另一个方法def pipeline(closure){ closure()} pipeline(code block)def stage(string name，closure){ printlnname closure()} stage(' Jenkins 'codeblock)

pipeline组成#

Jenkins PIP。

eline其实就是基于Groovy语言实现的一种DSL（领域特定语言），用于描述整条流水线是如何进行的。流水线的内容包括执行编译、打包、测试、输出测试报告等步骤。

从软件版本控制库到用户手中这一过程可以分成很多阶段，每个阶段只专注处理一件事情，而这件事情又是通过多个步骤来完成的，这就是软件工程的pipeline。Jenkins对这个过程进行抽象，设计出一个基本的pipeline结构。

pipeline{agentanystages{stage('Hello'){steps{echo'HelloWorld'}}}}

pipeline：代表整条流水线，包含整条流水线的逻辑。stage部分：阶段，代表流水线的阶段。每个阶段都必须有名称。本例中，build就是此阶段的名称。stages部分：流水线中多个stage的容器。stages部分至少包含一个stage。steps部分：代表阶段中的一个或多个具体步骤（step）的容器。steps部分至少包含一个步骤，本例中，echo就是一个步骤。在一个stage中有且只有一个steps。agent部分：指定流水线的执行位置（Jenkinsagent）。流水线中的每个阶段都必须在某个地方（物理机、虚拟机或Docker容器）执行，agent部分即指定具体在哪里执行。

以上每一个部分（section）都是必需的，少一个，Jenkins都会报错。

Jenkins的很多插件可以被直接拿来当作一个步骤使用。只要安装了这些适配了Jenkinspipeline的插件，就可以使用其提供的pipeline步骤。

Jenkins官方还提供了pipeline步骤参考文档（https：//jenkins.io/doc/pipeline/steps/）。

post部分#

根据pipeline或阶段的完成状态，post部分分成多种条件块，包括：

•always：不论当前完成状态是什么，都执行。
•changed：只要当前完成状态与上一次完成状态不同就执行。
•fixed：上一次完成状态为失败或不稳定（unstable），当前完成状态为成功时执行。
•regression：上一次完成状态为成功，当前完成状态为失败、不稳定或中止（aborted）时执行。
•aborted：当前执行结果是中止状态时（一般为人为中止）执行。
•failure：当前完成状态为失败时执行。
•success：当前完成状态为成功时执行。
•unstable：当前完成状态为不稳定时执行。
•cleanup：清理条件块。不论当前完成状态是什么，在其他所有条件块执行完成后都执行。post部分可以同时包含多种条件块。

下面给出一个例子：

pipeline支持的指令#

基本结构满足不了现实多变的需求。所以，Jenkinspipeline通过各种指令（directive）来丰富自己。指令可以被理解为对Jenkinspipeline基本结构的补充。

Jenkinspipeline支持的指令有：

•environment：用于设置环境变量，可定义在stage或pipeline部分。
•tools：可定义在pipeline或stage部分。它会自动下载并安装我们指定的工具，并将其加入PATH变量中。
•input：定义在stage部分，会暂停pipeline，提示你输入内容。
•options：用于配置Jenkinspipeline本身的选项，比如options{retry（3）}指当pipeline失败时再重试2次。options指令可定义在stage或pipeline部分。
•parallel：并行执行多个step。在pipeline插件1.2版本后，parallel开始支持对多个阶段进行并行执行。
•parameters：与input不同，parameters是执行pipeline前传入的一些参数。
•triggers：用于定义执行pipeline的触发器。
•when：当满足when定义的条件时，阶段才执行。

在使用指令时，需要注意的是每个指令都有自己的“作用域”。如果指令使用的位置不正确，Jenkins将会报错。

配置pipeline本身（option指令）（用到的时候可以来参考这块）#

options指令用于配置整个Jenkinspipeline本身的选项。根据具体的选项不同，可以将其放在pipeline块或stage块中。以下例子若没有特别说明，options被放在pipeline块中。

•buildDiscarder：保存最近历史构建记录的数量。当pipeline执行完成后，会在硬盘上保存制品和构建执行日志，如果长时间不清理会占用大量空间，设置此选项后会自动清理。

参考这个文档：https://weread.qq.com/web/reader/12f320007184556612f32b6k1ff325f02181ff1de7742fc

这节比较有用，可以参考下

在声明式pipeline中使用脚本#

Jenkinspipeline专门提供了一个script步骤，你能在script步骤中像写代码一样写pipeline逻辑。

pipeline{agentanystages{stage('Hello'){steps{script{defs="HelloWorld"printlns}echo'HelloWorld'}}}}

可以看出，在script块中的其实就是Groovy代码。大多数时候，我们是不需要使用script步骤的。如果在script步骤中写了大量的逻辑，则说明你应该把这些逻辑拆分到不同的阶段，或者放到共享库中。共享库是一种扩展Jenkinspipeline的技术

pipeline内置基础步骤（重要）#

Jenkins的pipeline内置了很多基础步骤，我们可以直接使用。

参考章节：https://weread.qq.com/web/reader/12f320007184556612f32b6k4e73277021a4e732ced3b55

4.环境变量与构建工具#

环境变量#

环境变量可以被看作是pipeline与Jenkins交互的媒介。比如，可以在pipeline中通过BUILD_NUMBER变量知道构建任务的当前构建次数。环境变量可以分为Jenkins内置变量和自定义变量。

1.内置环境变量

使用方式：

小技巧：在调试pipeline时，可以在pipeline的开始阶段加一句：sh'printenv'，将env变量的属性值打印出来。这样可以帮助我们避免不少问题。

不推荐方法三，因为出现变量冲突时，非常难查问题。

Jenkins的控制台也对内置的环境变量做了说明，可以自己打开看下。

2.自定义环境变量

environment指令可以在pipeline中定义，代表变量作用域为整个pipeline；也可以在stage中定义，代表变量只在该阶段有效。

pipeline{agentanyenvironment{DEVOPS_IP='10.50.1.50'}stages{stage('Hello'){environment{NAME='HelloWorld...'}steps{echo"${DEVOPS_IP}"echo"${NAME}"sh'printenv'}}}}

但是这些变量都不是跨pipeline的，比如pipelinea访问不到pipelineb的变量。在pipeline之间共享变量可以通过参数化pipeline来实现。

在实际工作中，还会遇到一个环境变量引用另一个环境变量的情况。在environment中可以这样定义：

在定义变量的时候，为了防止变量冲突，建议将变量加上前缀（自定义的环境变量会覆盖默认的环境变量）。

3.自定义全局环境变量

env中的变量都是Jenkins内置的，或者是与具体pipeline相关的。有时候，我们需要定义一些全局的跨pipeline的自定义变量。

进入ManageJenkins→ConfigureSystem→Globalproperties页，勾选“Environmentvariables”复选框，单击“Add”按钮，在输入框中输入变量名和变量值即可。

自定义全局环境变量会被加入env属性列表中，所以，使用自定义全局环境变量与使用Jenkins内置变量的方法无异：${env.gname}。

构建工具#

构建每一步都是可重复的，尽量与机器无关。所以，构建工具的安装、设置也应该是自动化的、可重复的。

虽然Jenkins只负责执行构建工具提供的命令，本身没有实现任何构建功能，但是它提供了构建工具的自动安装功能。

1.tool指令

tools指令能帮助我们自动下载并安装所指定的构建工具，并将其加入PATH变量中。这样，我们就可以在sh步骤里直接使用了。但在agentnone的情况下不会生效。通过命令sh"printenv"，可以看到环境变量的所有值。

tools指令默认支持3种工具：JDK、Maven、Gradle。通过安装插件，tools指令还可以支持更多的工具。

配置maven

进入ManageJenkins→GlobalToolConfiguration→Maven页，设置如下图所示。

pipeline{agentanyenvironment{DEVOPS_IP='10.50.1.50'}tools{maven'maven.3.6.3'}stages{stage('Hello'){environment{NAME='HelloWorld...'}steps{echo"${DEVOPS_IP}"echo"${NAME}"sh'printenv'sh'java-version'sh'mvn-v'}}}}

这样，当执行到tools指令时，Jenkins会自动下载并安装Maven。将mvn命令加入环境变量中，可以使我们在pipeline中直接执行mvn命令。

ConfigFileProvider插件可以设置全局的setting设置。

利用环境变量支持更多的构建工具#

如果想让Jenkins支持更多的构建工具，也是同样的做法：在Jenkinsagent上安装构建工具，并记录下它的可执行命令的目录，然后在需要使用此命令的Jenkinspipeline的PATH环境变量中加入该可执行命令的目录。

利用tools作用域实现多版本编译#

在实际工作中，有时需要对同一份源码使用多个版本的编译器进行编译。tools指令除了支持pipeline作用域，还支持stage作用域。

在打印出来的日志中，会发现每个stage下的JAVA_HOME变量的值都不一样。

5.代码质量#

静态代码分析#

使用maven插件在某个stage加入静态代码分析。（静态代码扫描通常被安排在编译之后）

单元测试#

性能测试#

Jenkins集成SonarQube（有时间将这个环境搭建起来，将分析报告推送到GitLab）#

Allure测试报告（美化测试报告，不是重点）#

6.触发pipeline执行#

自动化是指pipeline按照一定的规则自动执行。而这些规则被称为pipeline触发条件。

对于pipeline触发条件，可以从两个维度来区分：时间触发和事件触发。接下来，我们从这两个维度分别介绍。

时间触发#

时间触发是指定义一个时间，时间到了就触发pipeline执行。在Jenkinspipeline中使用trigger指令来定义时间触发。

tigger指令只能被定义在pipeline块下，Jenkins内置支持cron、pollSCM，upstream三种方式。其他方式可以通过插件来实现。

使用场景：一些比较重的任务可以放到凌晨再跑。

事件触发#

事件触发就是发生了某个事件就触发pipeline执行。这个事件可以是你能想到的任何事件。比如手动在界面上触发、其他job主动触发、HTTPAPIWebhook触发等。

常用的有下面几种：

由上游任务触发：upstream（其他job来触发）GitLab通知触发在pipeline中实现GitLabtrigger

将构建状态信息推送到GitLab#

GenericWebhookTrigger#

安装GenericWebhookTrigger插件（下文使用GWT简称）后，Jenkins会暴露一个API：＜JENKINSURL>/generic-webhook-trigger/invoke，即由GWT插件来处理此API的请求。

如何处理呢？GWT插件接收到JSON或XML的HTTPPOST请求后，根据我们配置的规则决定触发哪个Jenkins项目。基本原理就这么简单。

7.多分支构建#

在实际项目中，往往需要多分支同时进行开发。如果为每个分支都分别创建一个Jenkins项目，实在有些多余。

不同分支发布不同环境#

when指令的用法#

when指令允许pipeline根据给定的条件，决定是否执行阶段内的步骤。when指令必须至少包含一个条件。when指令除了支持branch判断条件，还支持多种判断条件。

这块内容非常有用，可以经常参考。

https://weread.qq.com/web/reader/12f320007184556612f32b6k9a132c802349a1158154a83

GitLabtrigger对多分支pipeline的支持#

GenericWebhookTrigger插件在多分支pipeline场景下的应用#

在多分支pipeline场景下，我们希望触发某个分支的构建执行。

8.参数化pipeline#

什么是参数化pipeline#

参数化pipeline是指可以通过传参来决定pipeline的行为。

使用parameters指令#

parameters{stringdefaultValue:'none',description:'字符串',name:'D_ENV',trim:truetextdefaultValue:'a\nb\nc\n',description:'文本',name:'D_TEXT'choicechoices:'a\nb\nc\n',description:'选一个',name:'D_CHOICE'booleanParamdefaultValue:false,description:'布尔值参数',name:'FLAG'passwordname:'PASSWORD',defaultValue:'SECRET',description:'password'}

参考这个文章：https://zhuanlan.zhihu.com/p/80622378。

由另外一个pipeline传参数#

可以在一个pipeline中“调用”另一个pipeline。在Jenkinspipeline中可以使用build步骤实现此功能。build步骤是pipeline插件的一个组件，所以不需要另外安装插件，可以直接使用。

build步骤其实也是一种触发pipeline执行的方式，它与triggers指令中的upstream方式有两个区别：

（1）build步骤是由上游pipeline使用的，而upstream方式是由下游pipeline使用的。

（2）build步骤是可以带参数的，而upstream方式只是被动触发，并且没有带参数。

使用ConditionalBuildStep插件处理复杂的判断逻辑#

ConditionalBuildStep插件（https：//plugins.jenkins.io/conditional-buildstep）可以让我们像使用when指令一样进行条件判断。以下代码就是安装ConditionalBuildStep插件后的写法。

使用input步骤#

执行input步骤会暂停pipeline，直到用户输入参数。这是一种特殊的参数化pipeline的方法。我们可以利用input步骤实现以下两种场景：

（1）实现简易的审批流程。例如，pipeline暂停在部署前的阶段，由负责人点击确认后，才能部署。

（2）实现手动测试阶段。在pipeline中增加一个手动测试阶段，该阶段中只有一个input步骤，当手动测试通过后，测试人员才可以通过这个input步骤。

input步骤可以与timeout步骤实现超时自动中止pipeline，防止无限等待。以下pipeline一小时后不处理就自动中止。

9.凭证管理#

为什么要凭证管理#

在Jenkinsfile或部署脚本中使用明文密码会造成安全隐患。但是为什么还频繁出现明文密码被上传到GitHub上的情况呢

（1）程序员或运维人员不知道如何保护密码。

（2）管理者没有足够重视，否则会给更多的时间让程序员或运维人员想办法隐藏明文密码。

凭证是什么#

比如使用SSH登录远程机器时，用户名和密码或SSHkey就是凭证。而这些凭证不可能以明文写在Jenkinsfile中。Jenkins凭证管理指的就是对这些凭证进行管理。

为了最大限度地提高安全性，在Jenkinsmaster节点上对凭证进行加密存储（通过Jenkins实例ID加密），只有通过它们的凭证ID才能在pipeline中使用，并且限制了将证书从一个Jenkins实例复制到另一个Jenkins实例的能力。

也因为所有的凭证都被存储在Jenkinsmaster上，所以在Jenkinsmaster上最好不要执行任务，以免被pipeline非法读取出来。

创建凭证#

•Kind：选择凭证类型。

•Scope：凭证的作用域。有两种作用域：

◦Global，全局作用域。如果凭证用于pipeline，则使用此种作用域。

​◦System，如果凭证用于Jenkins本身的系统管理，例如电子邮件身份验证、代理连接等，则使用此种作用域。

•ID：在pipeline使用凭证的唯一标识。

添加凭证后，安装CredentialsBindingPlugin插件（https：//plugins.jenkins.io/credentials-binding），通过其提供的withCredentials步骤就可以在pipeline中使用凭证了。

常用凭证类型#

SecrettextUsernamewithpasswordSecretfileSSHUsernamewithprivatekey

优雅的使用凭证#

声明式pipeline提供了credentialshelper方法（只能在environment指令中使用）来简化凭证的使用。以下是使用方法。

https://weread.qq.com/web/reader/12f320007184556612f32b6k14b3246024514bfa6bb1534

使用HashiCorpVault（加强版的凭证管理工具）#

在Jenkins日志中隐藏敏感信息#

10.制品管理#

常见的制品管理仓库#

NexusArtifactory

版本号管理#

11.可视化构建及视图#

GreenBalls插件#

这个插件的功能是让构建成功的pipeline编程绿色。

BuildMonitorView插件#

BuildMonitorView插件（https：//plugins.jenkins.io/build-monitor-plugin）可以将Jenkins项目以一块“看板”的形式呈现。

视图#

使用视图可以对pipeline进行分组管理。

12.自动化部署#

部署和发布的区别#

部署是指将应用程序放到对应的服务器上。

发布是指用户能访问到新的功能点。

Jenkins集成Ansible实现自动化部署#

Ansible采用了与Puppet、Chef不一样的解决方案，不需要在受控机器上安装额外的客户端软件。原因是Ansible使用的是SSH协议与受控机器进行通信的，一般服务器默认有SSH服务。Ansible也因此被称为agentless（去客户端的）。

Puppet和Chef都自己做了一套DSL，而Ansible使用YAML格式作为自己的DSL格式。

13.通知#

邮件通知#

钉钉通知#

Http请求通知#

14.分布式构建与并行构建#

Jenkins的架构#

Jenkins采用的是“master+agent”架构（有时也称为“master+slave”架构）。Jenkinsmaster负责提供界面、处理HTTP请求及管理构建环境；构建的执行则由Jenkinsagent负责（早期，agent也被称为slave。目前还有一些插件沿用slave的概念）。

基于这样的架构，只需要增加agent就可以轻松支持更多的项目同时执行。这种方式称为Jenkinsagent的横向扩容。

对于Jenkinsmaster，存在单节点问题是显而易见的，但是目前还没有很好的解决方案。

在学习Jenkins的过程中，发现各种文档中掺杂着node、executor、agent、slave4个术语，新手很容易被它们弄得一头雾水。它们分别是什么意思呢？

•node：节点，指包含Jenkins环境及有能力执行项目的机器。master和agent都被认为是节点。

•agent：代理，在概念上指的是相对于Jenkinsmaster的一种角色，实际上是指运行在机器或容器中的一个程序，它会连接上Jenkinsmaster，并执行Jenkinsmaster分配给它的任务。

•slave：“傀儡”，与agent表达的是一个东西，只是叫法不同。

•executor：执行器，是真正执行项目的单元。一个执行器可以被理解为一个单独的进程（事实上是线程）。在一个节点上可以运行多个执行器。

增加agent#

https://weread.qq.com/web/reader/12f320007184556612f32b6k697324802676974ce5aceab

如何使用agent#

agent部分描述的是整个pipeline或在特定阶段执行任务时所在的agent。换句话说，Jenkinsmaster根据此agent部分决定将任务分配到哪个agent上执行。agent部分必须在pipeline块内的顶层定义，而stage块内的定义是可选的。

agentany告诉Jenkinsmaster任何可用的agent都可以执行。

agent部分的定义可以放在阶段中，用于指定该stage执行时的agent。

通过标签指定agent

customWorkspace，自定义工作目录。

不分配具体的agent

如果希望每个stage都运行在指定的agent中，那么pipeline就不需要指定agent了。

在默认情况下，阶段内所有的代码都将在指定的Jenkinsagent上执行。when指令提供了一个beforeAgent选项，当它的值为true时，只有符合when条件时才会进入该Jenkinsagent。这样就可以避免没有必要的工作空间的分配，也就不需要等待可用的Jenkinsagent了。

将任务构建交给Docker#

Docker拉取镜像时，默认是从Docker官方中心仓库拉取的。那么如何实现从私有仓库拉取呢？比如在“制品管理”章节中在Nexus上创建的私有仓库。

Docker插件为我们提供了界面操作，具体步骤如下：

进入ManageJenkins→ConfigureSystem页面，找到“PipelineModelDefinition”部分

DockerLabel：当pipeline中的agent部分没有指定label选项时，就会使用此配置。如docker{image'maven：3-alpine'}。

•DockerregistryURL：Docker私有仓库地址。

•Registrycredentials：登录Docker私有仓库的凭证。

并行构建#

可以用于优化构建速度。

一些名词#

pipelineascode

参考#

jenkins官网：https://www.jenkins.io/《Jenkins2.x实践指南》：https://weread.qq.com/web/reader/12f320007184556612f32b6kc81322c012c81e728d9d180《Jenkins权威指南》：https://weread.qq.com/web/reader/418326a07184553c4184bcekc81322c012c81e728d9d180最佳实践：https://www.cnblogs.com/lasdaybg/p/10175152.html最佳实践：https://blog.didispace.com/jenkins-pipeline-top-10-action/