🍭 概述
敏捷DevOps的一个主要目的是要达成持续的最短的周期进行价值交付 这就离不开快速的部署和发布
🍭部署和发布《DevOps实践指南》定义
🌴 部署
部署是指
在特定的环境中安装指定版本的软件
(例如,将代码部署到集成测试环境中,或者部署到生产环境中)具体的说
部署可能与某个特性的发布无关
如果部署与某个特性发布有关 因为部署后即时生效 即代表部署 = 发布
🌴 发布
(1)发布是指
把一个特性(或者一组特性)提供给所有客户或者一部分客户
(例如:向5%的客户群开放特性)(2)代码和环境架构要能够满足这种要求:
特性发布不需要变更应用的代码
(3)部署和发布是解耦开的 也就是:让🟠
部署可以独立于发布单独进行
而特性部署后,业务可以灵活决定什么时候发布
,向哪些目标客群发布。如果部署周期过长,就会限制向市场频繁地发布新特性的能力。如果能做到按需部署,或者持续部署,那么什么时候发布新特性,就成了业务和市场决策
,而不再是技术决策,所以🟠部署是技术范畴
,而🟠发布是业务范畴
(4)部署是技术范畴 发布是业务范畴(再次强调)
🍭持续部署概述
持续部署
(CD,Continuous Deployment)是将在预发、类生产环境中🎯经过验证确认的特性部署到生产环境
的过程,部署后这些特性就已经就绪,需要发布的时候随时发布
按需发布
(Release on Demand)是团队和企业的关键能力 按需发布使得业务具备持续的在最短的前置时间(Lead Time)内,以高频率的方式,让客户使用新功能,从而通过高价值方案响应市场机会为了
支持业务具备按需发布的能力
,特性在业务需要它们之前,必须在生产环境得到验证和等待发布。所以需要将部署
过程优化并从发布
过程中分离
出来,这样将代码变更部署到生产环境,并不会影响整个系统的行为。持续部署的能力使团队可以进行更小的增量的代码变更,并持续地部署到生产环境,但是并不发布,直到业务需要的时间才正式发布给客户。
而对于持续部署的“持续”,每个公司的程度是不一样的。如下图所示,《凤凰项目》提到国外的一些大厂2012年的部署频率和每次部署花费的时间(Deploy Lead Time)
持续的部署是业务按需发布的必要条件!
⚡持续部署实践
🌴 蓝绿部署(Blue-Green Deployments)
蓝绿部署是指有两个完全相同的、互相独立的生产环境
,一个叫做“蓝环境”,一个叫做”绿环境“ 绿环境是用户正在使用的生产环境
当要部署一个新版本的时候,先把这个新版本部署到蓝环境中,然后在蓝环境中运行冒烟测试,来检查是否正常工作
当一切准备就绪以后,向新版本迁移就非常简单了,只要修改一下路由配置,将用户流量从绿环境导向蓝环境就可以,这个时候蓝环境就变成了生产环境,这种切换通常在一秒钟之内就能搞定
如果出了问题,把路由器切回到绿环境上即可,然后在蓝环境中调试,找到问题的原因。所以蓝绿部署,是在部署之后,仅仅一次切换,立刻就向所有用户推出新版本,新功能对所有用户立刻生效可见。
⚡按需发布实践
🌴 金丝雀发布(Canary release)
🍩由来
软件行业的
金丝雀发布
这个术语来自20世纪初期英国煤矿工人在下井采矿之前会把笼养的金丝雀携带到矿井中
,如果矿井中一氧化碳
等有毒气体的浓度过高
,在影响矿工之前,金丝雀相比人类表现的更加敏感快速,金丝雀中毒之后,煤矿工人就知道该立刻撤离
🍩概述 灰度发布
是在金丝雀发布
基础上进行延伸
(1)金丝雀发布可以逐一发布新特性,而非完整的更新版本
(2)金丝雀发布会先将新功能提供给
一小部分用户
使用,根据小范围的用户反馈
对产品进行必要的调整
以保证软件不会出现严重问题,降低发布风险 因此金丝雀发布也被称之为按阶段发布
或者增量发布
🍩金丝雀发布基本通用步骤
1️⃣ 开发人员上传新版本(假设其为Version B)到服务器
2️⃣ 主要用户群体依旧定向到 Version A,与此同时,
小部分用户开始使用 Version B
,进而开发人员可以监控新版本
的性能
并进行改进3️⃣ 对 Version B 进行必要的调整之后,开发人员就会
将大部分流量定向到更新完毕的实例中
此时团队开始测量性能并将其与旧版本进行对比4️⃣ 当 Version B 已经足够稳定,开发人员就会切断 Version A 并
将流量完全重定向到更新后的代码库中
🍩优缺点分析
金丝雀发布的优势之一是可以✅
最大限度地减少宕机时间
并且避免新版本中存在潜在的问题
。 此外,通过在小部分用户中测试特性,开发人员可以在对更多用户产生影响之前发现并修复问题,这有助于确保
新功能或更新不
会对用户体验产生负面影响
这种部署模式也存在缺陷——❌
十分耗时
金丝雀的测试和部署是分几个阶段进行的,需要时间进行彻底的监控和评估。正因为如此,不是所有用户都能马上从新的功能和升级中受益
**🍩需要注意的是 **
正如许多
同时运行两个版本的部署策略
一样,开发人员需要牢记并确保技术栈和数据库的兼容性
🌴 灰度发布(Gray Release)
🍩概述
灰度发布
是在金丝雀发布
基础上进行延伸
,不是将发布分成两批,而是将发布分成不同的阶段/批次发布
,每个阶段/批次的用户数量逐级增加
如果新版本在当前阶段没有发现问题,就再扩展用户数量进入下一个阶段,直至扩展到全部用户
如下图所示,《持续交付2.0》提到的金丝雀发布与灰度发布示意图:
🌴 A/B测试(A/B Testing)-> 了解
简单来说,A/B测试是针对用户的需要,提供两个或多个版本的功能,一部分用户能看到版本A,一部分用户能看到版本B,一部分用户能看到版本C … 经过对比实验,得出
哪个版本更优
的测试过程A/B测试基于科学方法,对假设进行对照实验,即其他条件相同,只有一个条件不同的实验。
- 实验目标:为
同一个目标
(例如优化转化率或改进某些业务指标等)- 实验变量:针对
单一变量
(例如页面的按钮颜色发生了变化)- 实验方案:制定
两个或多个版本
(即A和B两个变体),在总体用户中取出一小部分,将这部分用户完全随机地分在两个组中,使两组用户在统计角度无差别,将两个版本分别展示给不同的用户组- 试验分析:有可能版本A是老版本称之为对照组,B是新版本称之为实验组,收集对照组和实验组组对应的用户体验数据和业务数据,最后分析、评估出最好版本,正式采用。
虽然 A/B 测试名字中只包含 A、B ,但并不是说它只能用于比较两个版本的好坏,事实上,
完全可以设计两个以上版本进行测试,比如A,B,C测试,即A/B/n测试
,“A/B 测试”这个名字只是一个习惯的叫法
【参考链接】https://zhuanlan.zhihu.com/p/354196385