jenkins pipeline类型

1，脚本式流水线

新建任务-选择流水线时，会有两种类型的配置

1.1 pipeline script：直接在Web UI的script输入框里面输入pipeline script语句即可，参考说明可以点击输入框下边的Pipeline Syntax，里面有很多示例操作说明，非常好用。
1.2 pipeline script from SCM：需要配置SCM代码存储Git地址或SVN地址，指定script文件Jenkinsfile所在路径，每次构建job会自动去指定的目录执行script文件。

以上两种方法定义Pipeline的语法都是一样的。

2，多分支流水线

新建任务-选择创建多分支流水线

multiBranch Pipeline的使用首先需要在每个分支代码的根目录下存放Jenkinsfile（Pipeline的定义文件），我们可以理解下maven的pom.xml文件，Jenkinsfile作为pipeline的管理文件也需要在源代码中进行直接的配置管理。这就要求devops工程师（QA、运维等）首先要有代码库的权限，或者至少赋能给dev工程师jenkinsfile的设计能力。

在multibranch pipeline job保存后，jenkins自动地检查所有的branch，且自动地为所有的branch创建job,当然前提是存在jenkinsfile文件。如果在代码库上某个branch分支被删除，multibranch pipeline也会自动检测变化并删除相应的job

这种模式主要的成本来自四个方面

1，我们在建立一个新工程的时候需要重新进行开发一遍Pipeline代码，即使你可以是copy的方式解决，但是依然会浪费一部分工作量，也不太符合code的理念（我们都希望尽可能的复用函数和功能，而不是重复的造轮子）
2，假如我们期望在build、deploy、测试完成后增加一个新功能(或者我们deploy的环境改变了)；例如笔者最近遇到的新需求–“静态代码检查”，我们期望给每一个工程都加上sonarqube检查，对于当前的解决方案来说，我们需要在64个工程增加此项功能并commit。
3，第三种情况，假如我们要针对不同的branch需要区分不同的行为，例如：我们期望所有的工程非master分支和develop分支不进行自动化测试，我们需要在不同的分支改动，并且在merge回master的时候常常还需要处理冲突
4，假如某一个工程需要迭代某个功能，我们需要将Jenkinsfile 从master merge到所有的branch