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