【DEVOPS】基于Jenkins + Ansible实现Windows环境下自动化打包部署

本文提供基于Jenkins + Ansible实现的Windows环境下的自动化部署解决方案。涵盖从代码提交入库到最终的部署完毕待提测整个流程。

1. 前言

废话不多说，直接进入正题，本文尝试提供一站式解决方案，解决Windows环境下研发侧的自动化部署问题。有任何问题欢迎留言，笔者将一如既往保持文章的更新。

整体思路是通过Jenkins提供友好的界面化操作，然后使用收集到的配置信息选择调用Maven，Ansible等来实现Windows环境下的全自动化部署。

完整流程图参见 CI - Jenkins+Ansible+Windows自动化部署解决方案 （这个流程图在被不断优化，所以如果发现图中的内容比本文描述内容多是一件很正常的事情 —— 20201106）。

惯例：为什么不使用Linux 和Docker的回答： 一言难尽！

2. 完整实现

整个流程中涉及三个角色（研发，产品经理，测试人员），两个阶段（开发阶段，发布阶段）。

2.1 三个角色

这里我们先就三个角色在其中的职责进行简要说明。

1. 研发人员。 主要负责业务代码编写，并在代码提交后执行专门的Jenkins Job（这一步已经修改为由SVN服务端的PostCommit钩子自动触发，参见【DEVOPS】快速实现SVN与Jenkins双向打通）。解决方案将确保新增代码通过最基本的检测——诸如编译错误，代码质量问题等（因为本解决方案刚刚开始执行，为了减小推进阻力，保护微小的改革火苗，我们决定先抓主线，在推进过程中慢慢补上这些必要的检查短板）。

2. 产品经理。确定当前产品的版本号。解决方案将确保按照约定的规则生成版本号并推送到制品库。
   
   最终效果：
   

3. 测试人员。按照需求指定测试环境参数以及指定的APP版本，并在收到部署完毕的通知之后进行相关测试工作。解决方案将确保按照需求快速生成相应的环境，并部署指定的APP版本。
   

2.2 两个阶段

分别为PACKAGE阶段和DEPLOY阶段。

2.2.1 PACKAGE阶段

关键点有两个：版本号的配置和元数据的写入。

1. 版本号的配置。
   在本流程中，版本号的决定权被交给了产品经理，因此我们提供了专门的UI供产品经理进行配置（相关截图参见上方的 "三个角色"之产品经理）。

   实现细节上，主要是要将原本的mvn clean deplay拆分，拆分出专门的"deploy"阶段，以实现自定义发布版本的需求。如下图：
   

2. 元数据的写入
   元数据是关于数据的数据。使用自动化杜绝原本不可捉摸的人工活动之后，我们需要对整个自动化流程进行留痕操作，确保整个流程的可追溯，快速定位问题以进行更好的优化。

   具体实现一块，我们采取是收集Jenkins Job Build相关信息，SVN提交信息等写入到专门的meta-info.md文件中，并在制品(例如这里的WAR)被推送到制品库之前将其写入到制品中。（实现细节参见上方截图）

2.2.2 DEPLOY阶段

主要分为环境的准备和应用的发布。

1. 环境的准备
   因为是Windows环境，所以我们需要将原本一个Dockerfile文件解决的问题拆分为一个个Ansible配置文件（不要说Windows下也可以安装Docker，问就是一言难尽）。
   以下以Tomcat的安装为例，演示如何进行Tomcat在Windows环境下的自动化安装。
   
   测试人员选择相应的部署服务器，Tomcat各端口，当前需要进行测试的项目，点击Build即可实现Tomcat的自动化安装。

2. 应用的发布
   在上一步部署好环境之后，接下来就该将应用发布到我们配置好的环境中了。
   
   测试人员选择上一步配置好的部署服务器，需要进行测试的APP版本，点击Build将应用部署到指定服务器上。

   这里的关键点是实现动态的版本清单：

   // 为了确保读到这里的读者能够快速理解，这里分别进行注释说明。
   
   // 获取用户输入的 groupId, artifactId
   def groupId = GROUP_ID
   def artifactId = ARTIFACT_ID
   // 防御性编程
   if(!groupId?.trim()){
          
     return ['请输入groupId']
   }
   if(!artifactId?.trim()){
          
     return ['请输入artifactId']
   }
   // 从制品库中获取指定groupId和artifactId的现有版本号清单
   def versions = ['bash','-c',"curl 'http://xx.xx.xx.xx:803/nexus/service/local/lucene/search?g=$groupId&a=$artifactId&collapseresults=true' -H 'accept: application/json,application/vnd.siesta-error-v1+json,application/vnd.siesta-validation-errors-v1+json'"].execute().text.readLines()
   // 使用Groovy解析JSON字符串
   def jsonSlpuer = new groovy.json.JsonSlurper()	
   def versionObjs = jsonSlpuer.parse(new java.io.ByteArrayInputStream(versions.get(0).getBytes()))
   // 取前十个版本
   if( versionObjs.data.size() > 10){
          
     return versionObjs.data[0..10].version
   } else{
          
     return versionObjs.data.version
   }
   

   这里再把配置界面贴一下。（注意选择的参数类型为" Active Choices Reactive Parameter "，如果你发现自己的Jenkins里没有整个选项，那就需要安装下Plugin - “Active Choices Parameter”）
   

2.2.3 DESTORY阶段

自动化带来的效率提升让我们对于环境准备不再提心吊胆，快速的环境重建变得非常普遍，因此我们还需要提供一个摧毁当前环境的操作。

这里依然以Tomcat为例。

用户在选择相应的服务器和相关应用之后，点击Build即可销毁相应的Tomcat以及其中的应用。

3. 感慨

站在此刻的时间点回头看，经历了过去两年无数次的热血沸腾到最终的黯黯神伤，自己在2018年开始推动的流程被竞品公司跑到了前面，不禁让人唏嘘。这次我们作出了不少妥协（暂时放弃Docker+K8S方案；放弃Linux部署，转而寻求Windows部署上的解决方案(网上资料真是少得可怜…)；实现笔者之前一直很抗拒的增量打包功能等），只是为了确保DEVOPS之旅真正开始启程。

4. Links

1. jenkins基于Ansible自动发布/回滚/管理spring boot/cloud一体化
2. Tomcat基于Jenkins+Ansible的自动发布(1)
3. Tomcat基于Jenkins+Ansible的自动发布(2)
4. 某小型公司持续集成工具jenkins实践（JAVA WEB、Android、IOS、html）
5. java web项目war包自动升级部署方案
6. 我是如何重构整个研发项目，促进自动化运维DevOps的落地？ 18年就关注的文章，直到现在才开始落地。