自动化发布
前言：
个人现在在 上海一家大数据挖掘公司：负责运维架构，自动化与系统运维相关工作，今天主要是整理了下现在团队APP发布流程：
方案：
因为在项目迭代的过程中，不可避免需要”上线”。上线对应着部署，或者重新部署；部署对应着修改；修改则意味着风险。
目前有很多用于部署的技术，有的简单，有的复杂；有的得停机，有的不需要停机即可完成部署。
个人整理下部署流程说明其实现在很多部署方法，现在我们用目前比较流行的几种部署方案，或者说策略方案对比总结简单讨论一下目前比较流行的几种部署方案，或者说策略。如有不足之处请指出，如有谬误，请指正^_^。
我们有自己开发环境和测试环境 ：
开发环境部署：
- 问题：
开发人员每个人在自己电脑环境写代码自己电脑本机测试代码是否run成功，每个开发人员都在自己本地写完测试出现问题是各自环境不统一导致遇到坑阻碍到测试人员测试，基础的bug也会浪费太多时间。
- 解决后：
主要是解决了给予开发团队在写代码或者修改bug可以第一时间更新部署。大家统一一个开发环境这个是为了在开发阶段能立马呈现效果。
测试环境部署：
- 问题：
一开始没有测试环境，直接开发环境当作测试环境去跑，发现很多问题，就是测试环境数据跟生产不一样，导致很多bug问题，测试发现测试的时候，开发在更新代码发布，耽误了测试人员的测试过程，环境不能独立都互相占用，刀子效率没有提高，bug每个星期都不断提升。
- 解决后：
主要解决了开发环境和测试环境独立，不会互相影响，测试人员有单独环境去测试生产能准确的数据对比。
选择灰度环境部署方案：
先贴个百度百科：
灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
灰度环境部署:
个人理解灰度部署是增量发布的一种类型，它的执行方式是在原有软件生产版本可用的情况下，同时部署一个新的版本。同时运行同一个软件产品的多个版本需要软件针对配置和完美自动化部署进行特别设计。
1 | (1) 准备好部署各个阶段的工件，包括：构建工件，测试脚本，配置文件和部署清单文件。 |
第1步: 把绿色集群的状态改为’备用’. 从负载均衡的池里把这些地址去掉,这样,绿色的集群就不再回接收到来自用户的请求了.转而进入备用负载均衡的池里.
选择蓝绿环境部署方案：
蓝绿发布的意义
整个发布过程，用户没有感受到任何宕机或者服务重启。
蓝绿发布的过程
- 第0步:部署以前的配置
.png)
- 第1步: 把绿色集群的状态改为’备用’. 从负载均衡的池里把这些地址去掉,这样,绿色的集群就不再回接收到来自用户的请求了.转而进入备用负载均衡的池里.
.png)
- 第2步:在绿色集群里部署新的代码,直到应用启动成功
.png)
- 第3步:使用备用负载均衡简单测试一下备用集群的部署情况.理想状态下是全自动的.
- 第4步:把绿色备用集群的状态改成存货,于是进入了存活负载均衡的池里
看到 蓝色运行v1版本,绿色运行v2版本,都连接的是相同的数据库.这意味着v2版本也要在老的数据模型上运行.如果数据库有变更,要等到所有的集群升级到新的代码上. - 第5步: 对蓝色集群也进行同样的操作.
.png)
.png)
- 最终v2代码完成部署.
.png)
- 第6步:根据情况.运行数据库迁移
参考：tks green-deployment
总结：
蓝绿部署：不停止老版本，额外搞一套新版本，等测试发现新版本OK后，删除老版本。其实这里删除老版本也就是重新部署了老版本成为新版本一起放上去，等需要更新发布迁下期中一个版本环境部署：现在我们公司使用蓝绿部署方案。
灰度发布：不停止老版本，额外搞一套新版本，常常按照用户设置路由权重，例如90%的用户维持使用老版本，10%的用户尝鲜新版本。不同版本应用共存，经常与A/B测试一起使用，用于测试选择多种方案。