常见代码部署方式
1 蓝绿部署介绍
两个完全一样的生产环境配置部署的两套产品，一个是当前正在运行的生产环境，它接收所有用户流量(蓝色)。另一个是它的克隆，但是是空闲的(绿色)。两者使用的配置，数据库，主机等全部一致
具体过程
当前版本业务正常访问 (蓝色) ；
另一套环境部署新代码 (绿色) ，代码可能是增加功能或修复 BUG ；
测试通过后将用户请求流量全部切到新版本 (绿色) 环境；
观察测试，若新版本 (绿色) 稳定无异常，表示本次蓝绿发布成功；
观察测试，若有异常直接切换旧版本（蓝色）；
下次升级，将旧版本 (蓝色) 所在环境升级到新版本，继续进行蓝绿发布，其特点是业务无中断，升级风险几乎为零；
适用场景
不停止老版本，另部署一套新版本；测试完成之后，删除老版本；
蓝绿发布是一种用于升级与更新的发布策略，部署的最小维度是容器，而发布的最小维度是应用
蓝绿发布对于增量升级有比较好的支持，但是对于涉及数据表结构变更等等不可逆转的升级，并不完全合适用蓝绿发布来实现，需要结合一些业务的逻辑以及数据迁移与回滚的策略才可以完全满足需求。
2 金丝雀发布介绍
金丝雀发布也叫灰度发布，是指在灰与白之间，能够平滑过渡的一种发布方式，灰度发布是增量发布的一种类型；灰度发布是在原有版本可用的情况下，同时部署一些新版本应用作为 “金丝雀(小白鼠)” 进行测试新版本的性能与表现等，以保障整个系统稳定持续正常运行的情况下，尽早发现、调整问题。
灰度起源 “金丝雀” 的由来：17世纪，英国矿井工人发现，金丝雀对瓦斯这种气味十分的敏感；空气中哪怕有及其微少的瓦斯，金丝雀也会停止歌唱；而当瓦斯超标后，虽然人类无法察觉，但是金丝雀早已毒发身亡；所以在当时设备简陋的情况下，工人们每次下井都会带一只金丝雀作为 “瓦斯检测指标” ，以便在危险情况下快速发现且撤离。 等同：在灰度发布的时候就可以进行发现、调整问题。
具体过程
准备好部署各个阶段的工件，包括：构建工件，测试脚本，配置文件和部署清单文件；
从负载均衡列表中移除掉 “金丝雀” 服务器；
升级 “金丝雀” 应用（排掉原有流量并进行部署）；
对应用进行自动化测试；
将 “金丝雀” 服务器重新添加到负载均衡列表中（连通性和健康检查）；
如果 “金丝雀” 在线使用测试成功，升级剩余的其他服务器（否则就回滚）。
适用场景
不停止当前版本(V1)，另部署一套新版本(V2)，不同版本进行共存；
灰度发布中，经常设置权重进行分流；比如95%持续老版本(V1)，5%尝试新版本(V2)；
经常与 A/B 测试一起使用，用于测试选择多种方案。
3 滚动更新介绍
滚动更新在 “灰度发布” 的基础上进一步优化改进，几乎为全自动化的发布方式，用户体验平滑；在滚动部署中，旧版本(V1)的应用程序会逐渐被替代为新版本(V2)，直至全体替换为新版本(V2)。
具体过程
在灰度发布的基础上进行递增升级；
从老版本集群开始自动递增替换1% > 10% > 20%… > 100% 直至100%滚动升级完成。
适用场景
对于容器有生命周期管理的 K8S 集群
整套环境自动化程度强
4 A/B测试介绍
A/B 测试用来同时测试两套生产环境不同的方案，同时测试应用功能的表现；比如可用性、受欢迎程度、可见性等
具体过程
A组与B组不同应用同时上线生产；
两套环境用来比较具体的差异；
与蓝绿毫无关系，蓝绿仅是一套正式在线。
适用场景
游戏上线新应用测试受欢迎程度，为迎来更多的收入；
评论区