案例简述
本文主要描述Jenkins 2.0多分支Pipeline框架改造实践，从背景描述、关键技术、方案框架等环节进行阐述，为项目的版本构建实践提供方案支持，同时也为其它项目的DevOps实践提供参考。适用于需要进行流水线升级的复杂多组件的老项目，通过CI 组件JOB标准化改造，利用Jenkins 2.0 Mulitbranch Pipeline脚本，实现版本自动拉取和监测，打造项目版本的持续交付流水线。
业务背景
针对项目代码托管仓库对应多个分支的版本维护常常遇到困难，当前主流的做法是参数化+手动构建的方式实现。同时，当前组件都是基于1.X 构建JOB配置，对大多数CI组件来说，希望能保持现有可视化配置，实现组件包的构建打包。
本方案通过脚本自动拉取分支后，能自动监测到新添加分支，完成该分支的版本构建、部署、测试和上传制品库。
关键技术考虑
1.Jenkins 2.0新特性---Pipeline
Jenkins2.0支持三种类型的Pipeline，后两种其实是批量创建一组普通Pipeline的快捷方式，分别对应于多分支的应用和多应用的大型组织。
- 普通Pipeline
- MultibranchPipeline
- Organization Folders
Pipeline设计三个基本概念：
- Stage: 一个Pipeline可以划分为若干个Stage，每个Stage代表一组操作。注意，Stage是一个逻辑分组的概念，可以跨多个Node。
- Node: 一个Node就是一个Jenkins节点，或者是Master，或者是Agent，是执行Step的具体运行期环境。
- Step:Step是最基本的操作单元，小到创建一个目录，大到构建一个Docker镜像，由各类Jenkins Plugin提供。
2.Multibranch Plugin
该插件通过指定托管仓库，提供Jenkinsfile后，系统会自动监控该仓库上的分支，通过配置规则对满足条件的分支运行Jenkinsfile脚本，实现项目版本的构建、部署、测试、发布等pipeline环节。
上线方案
总体框架支持两个场景触发操作：
1.拉取版本
版本管理员通过Jenkins Job拉取新版本，分支名称为待发布版本号，MulitiBranch Plugin扫描到该变更后，执行Pipeline进行构建、打包、部署、测试和上传制品库。
2.发布版本
版本管理员从制品库选择可用版本进行发布。框架包含三部分：
1）分支拉取
该部分由版本管理员触发，脚本自动关联项目各托管仓库，拉取相应分支，分支名称为版本号，脚本主体实现通过如下命令实现：
2）Pipeline框架
基于Mulitbranch Plugin，自动监控Gerrit/git上新创建分支，扫描并执行Jenkinsfile。由于项目涉及各组件JOB是各自配置的，框架需要按如下规则扫描出满足条件的组件JOB进行构建，参数为版本号。
业务JOB名称必须满足如下必要条件：
l 指定项目名称前缀，如ProjectA以”ProjectA_”前缀命名
l 指定构建后缀，如Package侧匀.以”_Package“后缀。
3）业务组件JOB构建
所有业务组件统一使用Jenkins Git Parameter插件提供JOB的参数化构建，以版本名称拉取分支名称，组件版本构建时支持选择指定分支进行版本构建，其中参数名为：PROJECTA_BRANCH，与框架传入的参数保持一致。
Pipeline环节实践
1.并发构建
通过jenkins pipeline groovey提供API（需要预研穿刺），模式匹配到满足条件的JOB后，参数化进行构建，参数为构建的分支名称。其核心代码如下：
2.校验打包
提供统一的打包组件版本ZIP包后添加校验，各组件的make.sh脚本最后增加一个组件（带路径）文件清单，在版本ZIP包构建完成后，调用 VerifyPackage.sh遍历清单中的文件条目进行检测，如果ZIP包中不存在清单文件，则校验失败，示例如下：
3.自动化部署
具体需要各项目自己适配，如大数据的自动化框架，根据领域Scala语言特性，打造使用REST调用的自动化测试基础框架，支持用例管理、日志分析、CI对接等功能。
4.自动化测试
提供通用的测试框架，输出结果如Junit风格，方便CI集成和问题定位。
5.制品库发布
利用公司制品库进行版本发布。
项目收益
通过实践可以解决以下两个问题：
1.自动化的版本管理
基于Jenkins2.0提供新插件进行二次开发，提取一套公共框架实现版本的自动拉取与构建测试，并在测试通过后上传制品库。
2.支持组件级构建解耦
对于一个涉及多组件的大项目来说，该框架支持业务组件仍使用原有的1.X JOB配置方式，维持组件原CI JOB方式不变，项目新的Pipeline和老CI构建的兼容，做到改动最小化。
