运维号
虽然我只是个开发人员，但是很多时候都是我们自己完成环境部署，目前我们测试环境实现了自动化部署，是基于Jenkins来做的；生产环境暂时还是【人肉】部署。整体的发布水平和很多公司还是有很大的差距，不过公司缺少一些基础平台，我们也只能自己想办法。
自动化发布，前置工作有很多
通过Jenkins实现自动化发布的过程很简单：
开发人员把代码通过git或者svn提交；
Jenkins可以通过手动或定时的方式启动，会更新最新的代码，跑全量的测试用例，测试通过后进行代码的部署；部署的过程都是提前写好的脚本，比如通过什么命令打包，把包放到哪台服务器的哪个目录下面，通过什么命令停止和启动（重启）服务。（具体的安装和配置，搜索一下会找到很多资料）
自动化发布看起来非常简单，但实际上前置工作很多：
- 需要有代码版本控制工具：这个问题不大，基本上每个公司都会有，最常用的git和svn；需要告诉Jenkins项目的代码在哪里。
- 自动化构建工具：如Maven、Gradle、Ant，我们基本都用Maven，个别特别老的项目用的Ant；需要告诉Jenkins项目执行什么命令可以打包。
- 整包发布：我了解还是有不少公司喜欢增量发布，但是我觉得如果能做到全量发布的话是最好了，能避免很多的问题。
- 单元测试：很多人会忽视这个问题，我还是觉得很有必要的；写单元测试要发自内心地觉得有用，而不是为了追求测试覆盖度，不是为了做给领导看。
- 灰度发布和回滚：这一点我们也没有做到，上线就是全部都上线，有问题的话就全部回退；我们项目尽量做到了【人肉灰度发布】，也就是先更新一个server，然后验证通过之后，再更新下一个；回滚也是人肉操作。
- 容器：要是公司用到了容器的话，那么自动化发布会容易一些...
人肉发布，想尽办法减少工作量
因为很多基础平台没有（我们公司很多工作都做了细分），一些事情的推进不是开发就可以推进的，通常需要很多部门的配合；所以生产环境依然还是手动发布。
拆包：我们项目是纯接口的项目，没有页面；项目被拆成了几个包，有单独一个包是对外提供服务的，也就是说，其余几个包随时可以在线发布，反正对用户是无感的；
编写各种shell脚本：既然做不到自动化发布，那么就让发布尽可能简单；可以把发布过程中一系列的命令，都写到shell脚本里面完成；
伪灰度发布：对外提供接口的包被部署在N个server上（使用Spring Boot内嵌的Tomcat），前面挂着Nginx，Nginx可以监控每个server（节点）的存活，所以发布的时候先停掉一个server做程序更新，Nginx会知道这个server不存活，这时候不会再发送新的请求到这个server上，直到程序更新完成启动。
我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。
分享到:
