GitLab的基础使用-常见的代码部署方式

　　　　　　　　　　GitLab的基础使用-常见的代码部署方式

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　作者：尹正杰

版权声明：原创作品，谢绝转载！否则将追究法律责任。

 

 

 

一.蓝绿部署

1>.什么是蓝绿部署

　　蓝绿部署指的是不停老版本代码(不影响上一个版本访问),而是在另外一套环境部署新版本然后进行测试，测试通过后将用户流量切到新版本。

　　优点:
　　　　业务无终端,升级风险相对较小。

2>.蓝绿部署具体过程

　　1>.当前版本业务正常访问(V1);

　　2>.在另外一套环境部署新代码(V2),代码可能是增加了功能或者修复了某些Bug;

　　3>.测试通过之后将用户请求流量切到新版本环境;

　　4>.观察一段时间，如有异常直接切换旧版本;

　　5>.下次升级,将旧版本升级到新版本(V3);

3>.蓝绿部署使用场景

　　1>.不停止老版本,额外部署一套新版本,等测试发现新版OK后，删除老版本;

　　2>.蓝绿发布时一种用于升级与更新的发布策略,部署的最小维度时容器，而发布的最小维度是应用;

　　3>.蓝绿发布对于增量升级有比较好的支持,但是对于设计数据表结构变更等等不可逆的升级,并不完全合适蓝绿发布来实现，要结合一些业务的逻辑以及数据迁移的回滚的策略才可以完全满足需求。

 

二.金丝雀发布

1>.什么是金丝雀发布

　　金丝雀发布也叫灰度发布,是指在黑与白之间，能够平滑过渡的一种发布方式，灰度发布时增量发布的一种类型，恢复发布时原有版本可用的情况下，使用部署一个新版本作为"金丝雀"(小白鼠),测试新版本的性能和表现，以保证系统稳定的情况下，尽早发现，调整问题。

　　"金丝雀"的由来:
　　　　17世纪，英国矿井工人发现，金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯，金丝雀也会停止唱歌。当瓦斯含量超过一定限度时，虽然鲁钝的人类毫无察觉,金丝雀早毒发身亡。
　　　　当时在狂劲设备相对简陋的条件下，工人们每次下井都会带上一直小金丝雀作为"瓦斯检测指标",以便在危险状态下紧急撤离。

2>.金丝雀(灰度)发布具体过程

　　1>.准备号部署各个阶段的工件，包括构建工件，测试脚本，配置文件和部署清单文件;

　　2>.从负载均衡列表中移除"金丝雀"服务器;

　　3>.升级"金丝雀"应用(排掉原有流量并进行部署);

　　4>.对应用进行自动化测试;

　　5>.将"金丝雀"服务器重新添加到负载均衡列表中(连通性和健康检查);

　　6>.如果"金丝雀"在线使用测试成功，升级剩余的其它服务器,否则就回滚;

　　温馨提示:
　　　　灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现，调整问题，以保证其影响度。

3>.灰度发布(金丝雀部署)使用场景

　　1>.不停止老版本，额外搞一套新版本,不同版本应用共存;

　　2>.灰度发布中,常常安装用户设置路由权重，例如"90%"的用户维持使用老版本，10%的用户尝鲜新版本;

　　3>.经常与A/B测试一起使用，用于测试选择多种方案。

 

  

三.滚动发布

　　滚动发布一般时取出一个或者多个服务器停止服务，执行更新，并重新将其投入使用。周而复始，直到集群中所有的实例都更新成新版本。

 

四.A/B测试

　　A/B测试也是同时运行两个APP环境，但是蓝绿部署完全是两码事;

　　A/B测试是用来测试应用功能表现的方法,例如可用性，受欢迎程度，可见性等等;

　　蓝绿部署的目的是安全稳定地发布新版本应用，并在必要时回滚;

　　综上所述,蓝绿部署是一套正式环境在线，而A/B测试是两套正式环境在线。

 

 

 

五.