- 整个项目组有32个java应用，10个javascript应用以及若干其他应用，并且还有增加的趋势；
- 3套测试环境，测试发布非常频繁，并且有同一个应用不同分支并行测试的情况；
- 版本管理器gitlab在公司内网局域网，测试环境在公网的青云主机上；
- Java应用在测试环境，可能有单节点或多节点部署；
- Java应用非常多，内存吃紧，需要合理部署应用在主机上，并且增加限制内存使用的启动参数；
- Java应用有多种部署及启动方式，有tomcat部署的，有一个整的jar包方式部署的，有jar包与配置文件分离并且主要配置都在配置管理中心的部署方式；
- 代码管理分支策略方式为，从master分支切出功能开发分支，并且其他分支提交到master分支的变更及时合并到此开发分支用以消除代码冲突，此分支发布生产环境之后，合并到master分支；
- 配置文件繁多，不同的环境配置文件不同；
二、multibranch pipeline介绍及实现构想
1、简单介绍：
A、先介绍下什么是Jenkins 2.0，Jenkins 2.0的精髓是
- Jenkins、nexus和gitlab都在公司内网局域网，测试环境都是青云云主机；
- 测试环境由一台专门的中转主机（transfer station），打包之后的包文件先上传到这个中转主机上，然后再分发到对应的测试环境的主机；
- 测试环境的主机，启动java应用进程，结束java应用进程，删除旧的包，传输新的包，全部是Jenkins的主机通过ansible控制；
- Multibranch pipeline方式，gitlab上项目的master分支，增加Jenkinsfile文件。
- 通过Jenkins的pipeline流水线作业，完成了从编译构建到部署的全部过程，即持续部署（continue deploy）。
- 为了简化过程，gitlab用户名密码保存在Jenkins主机的linux系统上，Jenkins主机ansible也是给测试环境主机分组并且用ssh密钥登录。
- 总结：Jenkinsfile文件放在gitlab项目master分支的根目录；Jenkins系统上配置multibranch pipeline项目；上传文件的shell脚本和部署应用的ansible playbook脚本都存放在Jenkins的主机上，Jenkinsfile中定义了调用这两个脚本。
四、发布过程涉及到的步骤
1、合并master分支代码；
2、替换不同环境的配置文件；
3、编译构建;
4、上传编译的包文件到linux主机；
5、结束应用的旧进程，替换包文件，重启应用。
五、Groovy DSL实现
1、Jenkins pipeline的代码实现，先将所有的变量都单独抽取出来，使用脚本编程方式。因为有合并master分支到测试分支的需要，所以得获取到Jenkins项目的环境变量：gitlab URL和分支名字；选择环境的变量使用"Extended Choice Parameter"插件；
2、合并master分支并且提交
3、替换配置文件，这里需要判断提供的路径指向的是目录还是文件
4、maven构建
5、上传构建完成后生产的包，调用shell脚本，其中包的相对路径、Jenkins的job名字和部署到的环境为三个参数变量
6、部署，需要三个参数，分布是Jenkins的job名字，部署到的环境，以及部署此java应用的ansible playbook剧本的绝对路径，因为剧本保存在Jenkins的主机上。
六、上传脚本
Shell脚本做了三件事：
- 根据Jenkinsfile调用脚本的时候给的包路径的参数，判断是否需要归档打包，如果需要打包则tar归档打包；
- Cksum在Jenkins主机上进行CRC校验；
- 上传包到中转主机的指定的路径，此处用scp通过公网上传。
七、ansible部署剧本
1、判读是否存在此应用的路径，记录结果，忽略报错
2、kill此应用的进程，如果步骤1的判断结果result是succeeded的时候
3、删掉旧的包文件，由于此处部署测试环境，无需备份保留，可以直接删除，条件也是步骤1的判断结果result是succeeded
4、从包中转机器下载包文件，条件也是步骤1的判断结果result是succeeded
5、cksum进行CRC校验
6、重新启动应用，捕获报错信息
7、返回进程ID
上传包的shell脚本和部署应用的ansible剧本中，很多命名都是统一了方式。
八、Jenkins配置job
1、新建multibranch pipeline项目
2、配置gitlab地址
3、构建配置
4、配置完毕之后保存，然后扫描分支
5、扫描出来分支，点进去，构建，这里会显示所有的变量
6、在控制台的输出中，能看到CRC校验值以及进程ID