Jenkins file :在Jenkins中，可以将管线配置与Jenkins分离。 在以前的Jenkins版本中，所有任务配置都保存在Jenkins主目录中作为配置文件。 这意味着，所有配置更改都依赖于Jenkins能够识别和管理这些文件(这非常困难，除非您想直接修改XML文件)。 在Jenkins 2中，可以通过DSL脚本在Web可视界面的文本区域中描述管线配置。 当然，也可以将这些文本格式的DSL代码与存储其他源代码的文本文件一起保存在外部版本控制系统中。 这样，您就可以像管理其他源代码一样以文件格式管理Jenkins任务，并支持历史记录跟踪和差异比较等功能。
在Jenkins 2中，建议使用名为Jenkinsfile的文件来保存任务配置和管线信息。 每个项目和分支都有自己的Jenkins文件，其内容各不相同。 可以将所有代码写在一个Jenkins文件中，也可以通过共享库调用外部代码。 此外，DSL语句还可以将外部代码加载到脚本中。
enkinsfile作为标记文件。 这意味着，如果Jenkins发现工程源包含Jenkins文件，Jenkins将自动分析并执行项目或分支。 Jenkins还可以标识所需的源代码版本控制(SCM )项目和分支，并加载和执行Jenkins文件中的代码。 如果您熟悉Gradle构建工具，则此概念类似于在APP应用程序中定义的build.gradle文件。
新任务类型和插件：
在Jenkins 2中选择创建新工作项目时，系统会提示您选择新的任务类型。 你可以看到一些耳熟能详的类型，比如自由式项目，或者你从来没有见过的类型。
管线： qpdmn，管线类型项目旨在建立管线。 这是通过用Jenkins DSL编写代码实现的。 管道项目是本书主要讨论的项目类型。 正如已经指出的，管道可以用“脚本式”语法风格写，也可以用“宣言式”语法风格写。 这种项目类型的管线可以很容易地转换为Jenkins文件。
文件夹：这是一种可以将多个项目分类为一个项目的方法，而不是项目本身的类型。 请注意，这并不像Jenkins控制板中的传统“显示”选项卡那样根据项目列表进行过滤。 更确切地说，它类似于操作系统中的目录文件夹。 文件夹名称是项目路径的一部分。
组织：一些源代码版本控制平台提供了将多个代码库聚合到“组织”中的机制。 通过Jenkins集成，可以将Jenkins管道脚本存储为组织内代码库中的Jenkins文件并基于这些库执行。 目前支持GitHub和Bitbucket平台的组织功能，未来将支持其他平台。 为了简单起见，本书主要以GitHub的组织项目为例。 假设您具有足够的权限，Jenkins可以在代码托管端自动为您的组织创建webhook (站点通知)，并将任何基于代码的更改通知给Jenkins实例。 当Jenkins收到通知时，它会检测在代码库中用作标记的Jenkins文件，并执行其中的命令来执行管线。
多分支管线：在此类型的项目中，Jenkins再次使用Jenkinsfile作为标记功能。 如果在包含Jenkinsfile的项目中创建了新分支，Jenkins将基于该新分支自动创建新项目。 这种类型的项目可以应用于任何Git或SVN代码库。
新版本特性：管道被视为“一等公民”。 换句话说，管线在APP应用程序中被设计和支持为实体，而不是在Jenkins中将许多任务连接在一起以形成管线。
管道不仅可以构成接口，还可以用编码来描述。 这允许您使用在传统Jenkins中不可用或不存在的其他逻辑和工作流。
有专门用于流水线编程的结构化DSL。
可以直接在任务中以脚本形式创建管道，而不需要大量的Web表单交互。 也可以在Jenkins文件中完全单独创建。
保存为Jenkins文件的管线现在可以独立于Jenkins和源代码进行保存。
DSL提供了方便地在工作区中共享文件的功能。
支持使用更先进的内置Docker容器。
在Jenkins中编辑管线时有两种不同的语法样式：脚本语法(scriptedsyntax )和声明语法(declarative syntax )。
脚本语法(scriptedsyntax ) :脚本语法(scriptedsyntax )是Jenkins最初安装的流水线即代码方式。 这是一种指令型样式，用于在流水线脚本中定义逻辑和程序流。 它还取决于Groovy的语言和结构，尤其是在错误检查和异常处理时。
声明表达式语法(declarative syntax ) :声明表达式语法(declarative syntax )是由Jenkins提供的新选择。 宣告型式的管线代码组织成明确的段落，只关注实现逻辑，而这些管线的主要区域描述(或“宣告”)了我们所希望的管线的状态和输出。 在下面的代码示例中，上面是脚本语法，下面是相应的声明语法。
脚本流水线就像脚本和编程
语言，像其他命令式语言一样可以运行程序和处理逻辑，而声明式流水线则更像Jenkins的传统实现方式，在Web表单的预定义字段中输入关键信息，代表了特定目标和预期行为。与传统的Web表单类似，当执行声明式流水线时，每一个段落定义了基于用户输入数据的执行内容和方式。我们可以通过分析每种类型的优缺点，获取普遍规律和一些参考指导。
简而言之，脚本式流水线具有以下优点:
· 更少的代码段落和弱规范要求。
· 更强大的程序代码能力。
· 更像编写代码程序。
· 传统的流水线即代码模型，用户熟悉并向后兼容性。
· 更灵活的自定义代码操作。
· 能够构建更复杂的工作流和流水线。
脚本式流水线具有以下缺点：
· 普遍要求更高的编程水平。
· 语法检查受限于Groovy语言及环境。
· 和传统Jenkins模型有很大差异。
· 与声明式流水线的实现相比，同一工作流会更复杂。
声明式流水线具有以下优点:
· 更结构化，贴近传统的Jenkins Web表单形式。
· 更强大的声明内容能力，高可读性。
· 可以通过Blue Ocean图形化界面自动生成。
· 段落可映射到常见的Jenkins概念，比如通知。
· 更友好的语法检查和错误识别。
· 提升流水线间的一致性。声明式流水线具有以下缺点。
· 对迭代逻辑支持较弱（相比程序而言）。
· 仍在开发完善中（对于传统Jenkins中的部分功能缺乏支持）。
· 更严格的结构（更难实现自定义流水线代码）。
· 目前对于复杂的流水线和工作流难以胜任。
简而言之，对于新用户和那些希望流水线具备传统Jenkins一样可读性的用户来说，声明式流水线更容易学习和维护。这是以灵活性为代价换取结构不支持的功能。脚本式流水线更加灵活，提供了“超级用户”的选项，即允许用户不受结构约束实现更多功能。不过，总的来说，任何一种流水线类型对大多数场景而言都同样适用。
系统（system）：主节点（master）、节点（node）、代理节点（agent）和执行器（executor）… 不管我们使用脚本式语法还是声明式语法，每条Jenkins流水线都必须具备一个或多个系统用于执行代码。术语系统（system）在这里作为一种通用方法描述了我们所有需要讨论到的项目（item）。请记住，在任何给定的系统或机器上都可能运行着多个Jenkins实例。
…在传统Jenkins中只有两类节点：主节点（master）和从节点（slave），你可能已经非常熟悉这些概念了。下面是对一些相似概念的描述，主要为了对比突出差异点。
…Jenkins主节点是一个Jenkins实例（instance）的主要控制系统。它能够完全访问所有Jenkins配置选项和任务（job）列表。如果没有指定其他系统（system），它也是默认的任务执行节点。不过并不推荐在主节点上执行高负载任务，任何需要大量处理的任务都应该在主节点之外的系统上运行。这样做的另一个原因是，凡是在主节点上执行的任务，都有权限访问所有的数据、配置和操作，这会构成潜在的安全风险。同样值得注意的是，在主系统上不应该执行任何包含潜在阻塞的操作，因为主系统需要持续响应和管理各类操作过程。
节点:… 在Jenkins 2中，节点是一个基础概念，代表了任何可以执行Jenkins任务的系统。节点中包含主节点和代理节点，有的时候也用于指代这些概念。此外，节点也可以是一个容器，比如Docker。在任何Jenkins实例中主节点都会存在，但是由于上述原因，我们并不推荐在主节点上执行任务。
代理节点：… 在早先版本的Jenkins中，代理节点被称为从节点（slave），其代表了所有非主节点的系统。这类系统由主系统管理，按需分配或指定执行特定的任务。例如，我们可以分配不同的代理节点针对不同的操作系统构建任务，或者可以分配多个代理节点并发地运行测试任务。为了减少系统负载，降低安全风险，通常在子系统上只会安装一个轻量级的Jenkins客户端应用来处理任务，这个客户端应用对资源访问是受限的。随着代理节点和节点之间关系的演进，代理节点在节点上运行。在脚本式流水线中，“节点”特指一个运行代理节点的系统，而在声明式流水线中，其指代一个特定的代理节点来分配节点。
指令与步骤:… 根据节点和代理节点在声明式语法和脚本式语法中的使用方式，我们可以得出这两个概念之间的高层次的差异。node用于脚本式流水线，从技术层面上看它是一个步骤，代表可以用于流水线中执行活动的资源。它在一个运行代理节点的节点上面分配一个执行器，并进一步在定义的代码块上运行代码。下面的代码片段展示了一个指定node步骤的简单示例：
而相对于声明式流水线中的agent，它作为一个指令用来分配节点，除非使用了特殊用法agent none。下面是一个简单的agent声明的示例：
…执行器同上述所有系统都有关系。让我们来看看Jenkins如何定义这个术语。简单地说，执行器只是节点/代理节点用于执行任务的一个插槽。一个节点可以有任意多个执行器。执行器的数量定义了该节点可以执行的并发任务数量。当主节点将任务分配给特定节点时，该节点上必须有可用的执行器插槽来立即执行该任务，否则任务会一直处于等待状态，直到一个执行器变为可用。执行器的数量和其他参数可以在创建节点的时候进行配置，后面会介绍这一主题。
创建节点:在传统版本的Jenkins中，任务可以在主节点实例或者从节点实例上执行。在Jenkins 2的术语中，这些实例被统一成通用术语“节点”。建立新节点和过去添加从节点的方法是完全一样的。下面是一个简单的示例。
在管理节点界面中，选择新节点并填写表单，包括执行器数量:
在管理节点界面中，选择新节点并填写表单，包括执行器数量:
注意，在界面底部有环境变量和工具路径两个复选框。勾选这些复选框可以为该节点定义特殊变量和工具。只有zldxf希望使用与主节点不同的配置时，才会用到这些复选框;
标签可以满足系统和用户的不同需求，比如可以用于以下场景。
· 识别一个特定的节点（通过一个专有标签）。
· 对一类节点进行分组（通过分配相同的标签）。
· 识别节点的特征，方便使用（通过一个有意义的标签，比如“Windows”或者“West Coast”）。上面的最后一个场景是推荐场景。
更多关于不同启动方法和节点配置的信息，请查看Jenkins在线文档。一旦节点准备就绪，我们就可以专注于创建流水线了。我们将通过Jenkins DSL结构化程序来实现这一点。
Jenkins流水线的DSL基于Groovy语言实现。这意味着我们可以按照需求在流水线中使用Groovy语言的结构和习惯用法。但在通常情况下，我们倾向于避免使用过于复杂的Groovy代码，或者至少将其与主脚本分开。这样做的原因是，使用过多的Groovy代码会降低脚本的可读性和可维护性，尤其是对那些不了解Groovy的人来说。声明式流水线禁止使用定义结构之外几乎所有的Groovy代码，并且还提供了更多类似于传统Jenkins特性的功能，因此你必须尽量减少使用自定义Groovy代码。
下面是一个非常简单的Jenkins DSL流水线表达式：
…节点在管理Jenkins→管理节点界面中定义，操作方法和之前添加从节点的方法完全一致。每一个节点都会自动安装Jenkins代理节点来执行任务（注意，这里假设在Jenkins实例中已经添加了一个节点，并打上了worker1标签):
节点和代理节点:…在之前的Jenkins术语部分，我们已经介绍了节点和代理节点的区别。在这一部分中，代理节点特指在“非主节点”上运行Jenkins代码。这一行告诉Jenkins应该在哪个节点上运行这部分流水线。它将代码与节点上运行的Jenkins代理程序绑定起来。通过将定义的名称作为参数（标签）传递进来指定特定节点。这个节点或系统必须已被定义，并且Jenkins系统知晓它的存在。在这里你可以选择不提供标签，但是如果忽略标签，则需要了解它的运作机制。
· 如果master被配置为默认的执行节点，那么Jenkins会在master上执行任务（可以配置master为不执行任何任务）。
· 否则，节点标签为空（或者在声明式语法中使用agent any），Jenkins会在任意节点上找到第一个可用的执行器来执行任务。换言之，如果在这里指定多个名称（使用逻辑运算符）也是完全有效的，尤其zldxf需要基于多个维度来选择节点的时候（如地点、类型等）很有意义。下面的扩展内容介绍了如何使用这项功能。
为一个节点打多重标签:
你可以使用标准的逻辑运算符来指定多个标签，比如，“||”表示或，“&&”表示与:
为什么要这么做呢？假设你分别在美国的东西海岸拥有两套Linux系统。基于某些特定的操作场景，你可能希望某些Jenkins任务被发送到东海岸，而另一些则在西海岸执行。
那么在这个场景中，你可以为所有节点添加Linux标签，同时附加一个新的标签来表示所在地域，如east或west。一旦标签就绪，你就可以通过操作符和标签的组合来指定节点。例如，一个任务需要在东海岸的Linux节点执行，可以这样描述：
这种大括号结构（｛｝）被称为Groovy闭包，标记了流水线中与该节点关联的代码起止段落。闭包也类似于程序中传递的实体，最后一个语句代表了返回值。（请参阅Groovy文档以获取更多关于闭包的信息。）
节点和映射:
除了定义节点来执行指定阶段任务，节点还可以通过映射指定其他部分代码的执行位置，比如，下面是一个parallel结构的示例：
…在节点的定义中，我们可以将个人设置、DSL命令和逻辑组合在一个stage闭包中。阶段必须指定一个name，这提供了一种机制，可以用来描述这个阶段的职责。现有的阶段实质上并没有在脚本中做什么事情，仅在运行流水线时在输出中标识出这个阶段的位置。研发人员可以决定在一个特定阶段中包含多少流水线逻辑。然而，一个通用的实践是创建阶段来模仿传统流水线中的任务片段。例如，我们可以设计一个阶段来获取源码，一个阶段来编译源码，一个阶段来执行单元测试，一个阶段来执行集成测试等.
步骤：…阶段中包含了实际的Jenkins DSL命令，这在Jenkins术语中被称为步骤（step）。一个步骤是DSL定义中最基本的功能。它虽然不是Groovy命令，但是可以和Groovy命令搭配使用。在以下示例中，我们通过初始步骤来获取源码：
这种语法非常简单易懂，调用git指令并传递给它拉取代码的地址参数（使用安全的HTTP协议）。对完整的步骤语法而言，这是一种缩写格式。当在脚本中使用DSL时，步骤的缩写格式和完整格式语法都会碰到，所以有必要花点时间来更好地理解语法模型的细节。
Jenkins DSL中的步骤总是期望映射（命名）参数。为了说明这一点，下面有另一个版本的git步骤的定义：
请注意，在这里有两个命名参数，其映射到期望的值：branch等于’test’，url等于：
实际上，这种语法本身是Groovy所使用的映射语法的一种简写形式。［命名参数:value，命名参数:value］等同于［key: value， key: value］的Groovy映射语法。其中命名参数函数作为映射的关键字。
Groovy还允许跳过参数的圆括号。如果没有这些快捷方式，较长版本的步骤将是这样的：
在本例中只有url参数是必选参数。如果没有命名参数，那么默认的参数就是script对象。下面的示例是一个bat步骤，在Windows系统上运行批处理或shell脚本。按照标准完整版语法，命令类似如下：
这个命令可以简写：
现在我们已经理解了脚本式流水线的基本结构，接下来让我们创建一个Jenkins流水线任务，并使用相关工具创建一个脚本：
…不管是哪个版本的Jenkins，我们都是通过新建一个指定类型的项目来开始一个新项目的。Jenkins 2内置了流水线类型的项目支持。这种类型的项目提供了编写代码来定义流水线的环境。在刚开始接触这类项目的时候，理解如何配置和使用环境创建、编辑、运行和监控流水线是很有帮助的。Jenkins的流水线脚本既可以在流水线类型的Jenkins任务中创建，也可以定义在一个叫作Jenkinsfile的外部文件中。Jenkinsfile可以同代码保存在一起。我们会采用在流水线任务中创建脚本的方式来学习创建DSL脚本。Jenkinsfile可以在任何文本编辑器中创建，当然也可以从流水线任务中复制生成。然而，在调用外部资源等任务时，流水线也需要进行相关调整。