自动发布系统

本文仅供参考，可能仍然存在很多理解不深刻的地方
我先简单的描述一下，发布系统的一个发展历程，纯属个人见解，请勿见笑
发展历程：

• 第一代：手动部署，上传代码到服务器，然后修改配置，启动服务器等等 流程都差不多了 就封装一个shell脚本
• 第二代：web界面，既然都开始封装脚本了，是否需要有个界面，至少可以知道发布的状态，进度等信息，如开源工具ControlTier（rundeck）
• 第三代：自动部署，已经规范部署流程，可持续集成部署，更多关注业务层面，一键部署，操作更简单，配置更加复杂
• 第四代：云部署，类似docker容器，整个代码、运行环境、操作系统全部打包进行拷贝部署

本文主要还是围绕所谓的第三代进行讲解，我主要用过的工具有Ansible 与Linkedin 开源框架Glu
Ansible python开发 无Agent也就是没有客户端的，轻量级 用起来方便
Glu 带了客户端的，重量级 当然功能也要强大点，自带了控制台

当然 我做过的两个发布系统都是 基于上述两个工具 说白了 就是根据工具提供的API进行了二次封装开发

这次封装开发做了哪些事情？考虑的问题又有哪些了。。。请听我慢慢道来

首先简单谈谈封装的东西：

大致的一个发布流程是

1. 准备工作
   运维团队可以定制发布脚步，配置发布的相关细节，如灰度发布

2. 研发人员申请发布
   创建发布单 这里最重要的就是版本号 版本的控制太多要讲 下次开专题一起讨论，如svn版本号，git版本号，war包版本号
   其实在这一步后面做的事情可多了，如对代码进行code review，编译打包等等

3. 测试人员审批
   个人觉得在审批这一步，QA可以先发布代码到测试环境，经过一轮仔细测试，然后批准发布

4. 部署
   一键式部署，点击部署按钮这可以发布

5. 检测
   这是后台程序做的一系列检测，如流量是否正常

6. 回滚
   根据发布的版本号，可以选择性回滚到某一个版本，当然一般情况上，回滚到上一次发布版本

其次考虑的问题：

灰度发布：
灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。AB 发布就是一种灰度发布方式，先对A组进行发布，让一部分用户继续用B，A组发布完成后，一部分用户开始用A，如果用户对A没有什么反对意见，那么逐步扩大范围，将对B组进行发布，把所有用户都迁移到A上面来。灰度发布可以保证整体系统的稳定，对用户完全透明的升级，具备好的用户体验，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
上面是copy过来的术语解释，发布系统引入灰度的概念，主要是为了提供友好的用户体验。同时也可以在生产环境上小测一会，这样保证了线上环境的可靠性，这里面我们又引入了一个概念，灰度暂停

灰度暂停:
大概意思是 假设把机器分为4组，启用灰度暂停，则会发完一组，就好暂停后面3组发布，当然没有启用，就会一组一组发完
我们当时考虑的灰度发布，是针对每一个业务，每一个机房中灰度发布

流量：
既然采用了灰度发布，当然动态切除和恢复线上流量，将会是一个问题。为什么会有流量这一说法？因为对于war包的发布，大多数情况是需要重启tomcat或resin服务器的，当然php与python的部署，一般不需要。那我们是怎么样摘除流量的？其实就是简单的修改nginx的upstrems配置

报警：
当时由于公司使用了zabbix监控系统，如tomcat挂了，所以我们在发布前，事先屏蔽报警，那么就可以干坏事了。。。

容错阀值：
为什么要有这样一个值？目前假设有100台机器进行代码发布，99台发布成功了，不能因为1台机器发布失败，而认定此次发布失败，当然可以实现一些内部逻辑，去重试几次，而有人会好奇，为什么偏偏一台发布失败，这样子例子太多了，如硬件问题、手动上机器干了坏事、网络波动等等原因

机房并发度：
这可能是我们国内特有的性质，一般会在多个机房部署同一套代码。所以我们引入了允许几个机房同事进行发布

机房并行度是否需要暂停：
当选择允许暂停，则可以勾选发布哪几个机房，主要对于某些不稳定的版本，为了小范围线上环境测试使用

机器并发度：
很重要的，直接影响到了发布效率问题。这里跟流量切换有直接的关系，这个并发度，是指灰度发布中一组机器中，机器的并行发布数
如100台机器，分成4组，每组25台，当然这里我们配置的并发度最大为25，最小为1.假设配的是5，意思当发布一组机器时，同时允许5台机器发布，配置为1就是串行发布了，为什么这样做？为了保证发布最小粒度，影响也最小，发现问题立马回滚

通知机制：
最基本的，发邮件通知审批，发布结束，发布的结果等等

智能排错：
做到这一步就比较高上大了，简单的说，就是在发布的过程中，或出现各种各样的错误，系统根据这些错误智能解决，并进行发布。
如某次上线，有同学上生产环境手动改了了代码，导致SVN发布有冲突，系统可以自动解除conflict，然后进行发布
在或者，部分机器代码发布后，5XX状态码急速上升，智能回滚的等等

智能检测：
怎么样去做好一个智能检测，确实是一个比较大的问题，牵涉到了系统的各方面的健康状态？
我能想到的一些检测工作：
1、服务器是否启动
2、代码中有检测接口，请求该接口是否返回正常
3、版本号检测，是否发布正确的版本号

发布模式：
由于公司业务决定，例举一些我们的发布模式，简单讲讲
1、svn发布，这种通常比较简单直接svn更新到发布的版本号
2、tomcat发布，通常是war包发布
3、resin发布，类似tomcat
4、静态资源发布，zip包文件推送解压
5、nodejs发布，包括了svn发布与zip包发布
6、git发布，更加git的版本号发布
7、php与python发布 包含了svn、git、静态资源发布
8、定制化业务发布

就写到这里了，写多了，看不完，大家也懒得看，欢迎和大家交流