1.流水线的两种语法结构
	1.脚本式语法
		是Jenkins最开始实现的流水线即代码方式。这是一种命令式风格，也就是在流水线脚本中定义逻辑和程序流程。它也更依赖于Groovy语言
	和结构，特别是对于错误检查和异常处理来说。
	node('work_node1') {
		stage('Source') {
			git 'git地址'
		}
		stage('Compile') {
			sh '...'
		}
	}

	2.声明式语法
		是Jenkins提供的一种新的选择。声明式风格的流水线代码被编排在了清晰的段落中，相对于只关注逻辑实现，这些流水线的主要区域描述了
	我们所期望的流水线的状态和输出。
	pipeline {
		agent {label 'work_node1'}
		stages {
			stage('Source') {
				steps {
					git 'git地址'
				}
			}
			stage('Compile') {
				steps {
					sh '...'
				}
			}
		}
	}

	你可以这样理解：脚本式流水线更像是一种脚本或者编程语言，像其他命令式语言一样可以运行程序和处理逻辑，而声明式流水线则更像Jenkins传统方式实现，
在Web表单的预定义字段中输入关键信息，代表了特定目标和预期行为。与传统web表单类似，当执行声明式流水线时，每一个段落定义了基于用户输入数据的执行内容
和方式。
	
指令与步骤：
	node 用于脚本式流水线中，从技术层面上看它是一个步骤，代表可以用于流水线中执行活动的资源。它在一个运行代理节点上面分配一个执行器，并进一步在定义
的代码块上运行代码。
	而相对于声明式流水线中的 agent,它作为一个指令来分配节点，除非使用了特殊用法 agent none。
	抛开两种不同的流水线的语法规格，这两个概念之间的区别并不明显，甚至可以认为就是一回事。只需要记住node用于脚本式流水线，agent用于声明式流水线就够了。


2.流水线的运行系统
	1.主节点master :
		是一个Jenkins实例的主要控制系统，它能够完全访问所有Jenkins配置选项和任务列表，如果没有指定其他系统，它也是默认的任务执行节点。
	不过不推荐在主节点上执行高负载任务，任何需要大量处理的任务都应该在主节点之外的系统上运行。
		这样做的另外一个原因是，凡是在主节点上执行的任务，都有权限访问所有的数据，配置和操作，这样会造成安全风险。

	2.节点node :
		在Jenkins2中，节点是一个概念，代表了任何可以执行Jenkins任务的系统。节点包括了主节点和从节点，也可以指一个容器，如Docker。
	在任何Jenkins实例中主节点都会存在。

	3.代理节点agent	
		在早先的版本的Jenkins中，代理节点被称为从节点(slave)，其代表了所有非主节点系统。这类系统由主系统管理，按需分配或者指定执行特定的任务。
		随着代理节点和节点之间关系的演进，代理节点在节点上运行。在脚本式流水线中，'节点'特指一个运行代理节点的系统，而在声明式流水线中，其指代一个
	特定的代理节点来分配节点。

	4.执行器executor
		简单的说，执行器就是节点/代理节点用于执行任务的一个插槽。一个节点可以有任意多个执行器。执行器的数量定义了该节点可以执行的并发任务的数量。
	当主节点将任务分配给特定节点时，该节点上必须有可用的执行器插槽来立即执行该任务，否则任务会一直处于等待状态，直到一个执行器变为可用。
		执行器的数量和其他参数可以在创建节点的时候进行配置。


3.流水线的基本结构

node ('worker1') {
		stage('Source') {
			git 'git地址'
		}
	}
	1.节点(node)：
		可以配置标签，执行器数量，环境变量，工具路径等。

		节点标签：
			可以满足系统和用户的不同需求，比如可以用于以下场景：
				1.识别一个特定节点
				2.对一类节点进行分组
				3.识别节点的特征，方便使用

		每个节点都会自动安装Jenkins代理节点来执行任务。
			1.如果 master 被配置为默认的执行节点，那么Jenkins会在master上执行任务。
			2.否则，如果标签为空(或者在声明式语法中使用 agent any),Jenkins会在任意节点上找到第一个可用的执行器来执行任务。

		当这部分流水线被执行的时候，它会自动连接到指定节点并未执行代码创建一个工作空间，当执行器空闲时，就会在该目录中执行该代码。

	2.阶段(stage)
		在节点的定义中，我们可以将个人设置，DSL命令和逻辑组合在一个stage闭包中。阶段必须指定一个name,这提供了一个机制，可以用来描述这个
	阶段的职责。现有的阶段实际上并没有在脚本中做什么事情，仅在运行流水线时在输出中标识出这个阶段的位置。
		研发人员可以决定在一个特定的阶段中包含多少流水线逻辑。然后，一个通用的实践是创建阶段来模仿传统流水线中的任务片段。例如，我们可以设计
	一个阶段来获取源码，一个阶段来编译源码，一个阶段来执行单元测试，一个阶段来执行集成测试等。

	3.步骤(step)
		一个步骤是 DSL 定义中最基本的功能。它虽然不是 Groovy命令，但是可以和 Groovy 命令搭配使用。
		git 'git地址'

		理解步骤语法：
			Jenkins DSL 中的步骤总是期望映射参数。
			git branch:'test', url:'git地址'
			请注意，在这里有2个命名参数，其映射到期望的值：branch 等于 'test', url 等于'git地址'。实际上这种语法本事是 Groovy 所使用的映射语法
		的一种简写。[命名参数:value, 命名参数:value] 等同于 [key:value, key:value] 的 Groovy 语法。Groovy 还允许跳过参数的圆括号，如果没有
		这些快捷方式，较长版本的步骤是这样的: 
			git([branch:'test', url:'git地址'])
			还有一个小技巧：如果只有一个必选参数，同时只传递一个数值，那么参数名称可以被省略。如下：
			git 'git地址'


4.Jenkins 为流水线开发和运行提供的支持环境(以及相关工具)
	Jenkins 的流水线脚本既可以在流水线类型的 Jenkins 任务中创建，也可以定义一个叫做 Jenkinsfile 的外部文件中。


白色 => 阶段尚未执行
蓝色 => 运行中
红色 => 失败
绿色 => 成功
浅红色 => 阶段执行成功，但是下游的某个阶段出现失败

回放：
	可以让你在一次运行结果的基础上修改代码并在此触发流水线。这会保存一次全新的构建记录，但原始的代码依然保持从前的状态。