shell+jenkins 自动部署平台

以下是我们团队在项目中的一些实践，因团队还成立不是很久经验不是很足，项目工作很紧张，并且也没有太多精力去做这方面事情，所以做出来的东西很简单，奉承的一句话能解决问题为主，以后遇到问题再来解决。大家有什么更好的想法可以一起交流下！

项目背景

项目组成立之初，采取的传统手动部署的方式，服务端由开发提供 war 包手动上传 tomcat 服务器进行部署，静态资源则由开发上传 zip 包放到服务器指定目录。项目初期因为项目少不复杂，对版本控制要求不严，同时也没有太多人力去进行规划，所以只能采取这种方案。
在项目逐步成熟过程中，需求频繁的进行变更，项目需要通过不断的实验来确定方向，与此同时，项目的模块变的逐渐增多，项目的结构也变的日趋复杂，其中需要根据不同的环境进行不同的配置，并且需要制定一套可以适用于上线和预发布的流程，此时原先的手工部署方式已经变的无法满足需求。
同时因为需要对代码权限进行控制，不能让任何人都能够随意看到代码，所以通过专门的打包机器进行代码的集中控制。

方案思想

自动部署平台包括几个模块：

• 打包
• 部署
• jenkins 持续集成

其中大概的的流程是

1. 服务端:jenkins-->选择要打包的项目-->调用打包机器打包-->存放到指定的 git 目录中-->拉去文件选择机器进行部署-->重启服务器-->检查是否启动成功
2. 静态资源:jenkins-->选择要部署的静态资源-->拉取存放在 git 中的静态资源-->修改指定配置-->上传服务器-->刷新 cdn-->检查是否刷新成功

准备工作

打包环境:JDK+maven+git
集成工具:jenkins
部署环境:tomcat+ngnix+redis+memcached+mysql+zookeeper

具体实现

打包部署

服务端包括脚本:

注:其中涉及到不同服务器资源传输，若不是通过仓库，则是通过 scp 拷贝实现

1. 打包脚本

   • 功能:负责根据不同的环境，修改服务端项目中的配置文件，更改配置后打包将打包文件放到指定位置，同时生成打包版本的备份文件,还可以根据分支名进行打包
   • 注释:因为不同项目往往存在许多会根据环境不同的配置文件，此脚本主要负责更改参数配置，参数配置根据项目不同以及环境不同从打包配置文件中读取

2. 上传脚本

   • 功能:拉取最新服务器的代码，并且对项目打 tag;根据环境不同,上传打好的包到 git
   • 注释:这个脚本主要是为了解决 war 包的集中管理，在日常测试时，会对测试版本打好测试的 tag,并且将打好的 war 包上传到测试的部署仓库中，版本测试完成准备上线，拉取稳定的测试 tag 打线上包，并且上传到运维人员指定的部署仓库

3. 启停服务器脚本

   • 功能:负责服务端项目 tomcat 的启动停止
   • 注释:这个脚本主要负责拉取最新的部署 war 包，并放到指定的部署目录下，同时清理老版本文件，重新启动服务器，在启动后检查服务器是否启动成功

静态资源包括脚本:

注：前端开发都是将最新的静态资源代码打成包放到指定的仓库

1. 测试环境部署脚本

   • 功能:负责测试环境的静态资源拉取，并解压修改相应的配置文件，并放到指定目录发布

2. 线上环境的打包脚本

   • 功能:负责线上环境的静态资源拉取，并解压修改配置文件，上传到指定服务器

3. 线上环境部署脚本

   • 功能:负责拉取指定服务器静态资源文件，并同步到线上机器上，并且自动刷新指定项目的 cdn，并且检查是否刷新成功
   • 注释:刷新 cdn 是通过调用接口实现的，并且通过指定文件生成 md5 串文件与 cdn 文件进行对比是否一致进行检查

持续集成

注:jenkins 通过 node 控制各台服务器

jenkins 包括两部分:

1. 服务端代码部署及打包
2. 静态资源部署

其中 jenkins 提供了一个简单易于使用的操作界面，同时提供丰富的插件来支持，故选择将其作为持续集成平台，并且还提供参数化命令参数，以及项目间的依赖支持，在每次部署后，通过执行自动化检查项目是否可以进行测试。并且在测试完成后可以通过邮件及时提醒相应人员注意。

后续想法

• 目前正准备通过 zookeeper 进行配置的集中化管理，这样能方便的进行配置的增删改查，同时也能节省在频繁的配置变更中需要通过频繁变动脚本的困境，同时在线上也能实现配置的同步。
• 通过 docker 实现服务器的快速启停以及部署。docker 因其能充分利用服务器资源，并且以其隔离性不错和秒级启停对于项目的部署很有帮助，目前还在调研中