研发效率破局之道
葛俊
前Facebook内部工具团队Tech Lead
立即订阅
3343 人已学习
课程目录
已完结 39 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 为什么你要关注研发效能?
免费
研发效能综述 (3讲)
01 | 效能模型:如何系统地理解研发效能?
02 | 效能度量:效果不好甚至有副作用,怎么回事?
03 | 效能度量:如何选对指标与方法,真正提升效能?
研发流程 (7讲)
04 | 流程优化:怎样才能让敏捷、精益真正为我所用?
05 | 代码入库前:Facebook如何让开发人员聚焦于开发?
06 | 代码入库到产品上线:Facebook如何使用CI/CD满足业务要求?
07 | 分支管理:Facebook的策略,适合我的团队吗?
08 | DevOps、SRE的共性:应用全栈思路打通开发和运维
09 | 信息流通:让团队高效协同,让产品准确击中目标
10 | 答疑篇:反对996并不是反对奋斗
工程方法 (10讲)
11 | 研发环境:Facebook怎样让开发人员不再操心环境?
12 | 代码审查:哪种方式更适合我的团队?
13 | 代码审查:学习Facebook真正发挥代码审查的提效作用
14 | 质量与速度的均衡:让“唯快不破”快得更持久
15 | 开源:从Phabricator的开源历程看开源利弊
16 | 高效上云:如何用云计算来提高效能?
17 | 测试左移:测试如何应对新的开发模式?
18 | 蓝绿红黑灰度发布:这些五颜六色的发布到底怎么用?
19 | 不再掉队,研发流程、工程方法趋势解读和展望
20 | 答疑篇:如何平衡短期收益和长期收益?
个人效能 (11讲)
21 | 高效工作:Facebook的10x程序员效率心法
22 | 深度工作:聚焦最有价值的事儿
23 | 效率工具:选对用对才能事半功倍
特别放送 | 每个开发人员都应该学一些VIM
24 | VIM:如何高性价比地学习VIM的实用技巧?
25 | 玩转Git:五种提高代码提交原子性的基本操作
26 | Facebook怎样实现代码提交的原子性?
27 | 命令行:不只是酷,更重要的是能提高个人效能
28 | 从工作场景出发,寻找炫酷且有效的命令行工具
29 | 1+1>2,灵活的工具组合及环境让你的工作效率翻倍
30 | 答疑篇:关于价值导向和沟通
管理和文化 (6讲)
31 | 业务目标和技术目标两手抓:怎样打造高效团队?
32 | 从Netflix公开的著名PPT谈硅谷公司文化
33 | Facebook企业文化:工程师文化是创造力引擎
34 | Facebook工程师文化实践三大支柱之一做感兴趣的事
35 | Facebook工程师文化实践三大支柱之二拥有信息和权限
36 | Facebook工程师文化实践三大支柱之三绩效调节
结束语 (1讲)
结束语 | 超越昨天的自己,享受成长的快乐
研发效率破局之道
登录|注册

18 | 蓝绿红黑灰度发布:这些五颜六色的发布到底怎么用?

葛俊 2019-10-02
你好,我是葛俊。今天,我来和你聊聊最近流行的一些部署、发布方法,以及测试右移。
最近几年,我见到了很多跟颜色相关的部署、发布方法,比如蓝绿部署、红黑部署、灰度发布等。今天,我会首先与你分享它们的基本定义和要解决的根本问题;然后,与你一起深入看一看高效应用这些方法的基本原则,以及一些具体的实践。

各种部署方式的定义

我们先来看看蓝绿部署(Blue-green Deployment)、红黑部署(Red-black Deployment)和灰度发布(Gray Release ,或 Dark Launch)的定义和流程吧。

蓝绿部署

蓝绿部署,是采用两个分开的集群对软件版本进行升级的一种方式。它的部署模型中包括一个蓝色集群 A 和一个绿色集群 B,在没有新版本上线的情况下,两个集群上运行的版本是一致的,同时对外提供服务。
系统升级时,蓝绿部署的流程是:
首先,从负载均衡器列表中删除集群 A,让集群 B 单独提供服务。
然后,在集群 A 上部署新版本。
接下来,集群 A 升级完毕后,把负载均衡列表全部指向 A,并删除集群 B,由 A 单独提供服务。
在集群 B 上部署完新版本后,再把它添加回负载均衡列表中。
这样,我们就完成了两个集群上所有机器的版本升级。

红黑部署

取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《研发效率破局之道》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(3)

  • 日拱一卒
    你觉得金丝雀发布可以用在移动端应用或者桌面应用上吗?如果可以的话,大概要怎么实现呢?

    首先,我们目前一般都在采用红黑部署的模式,对于不重要的更新,偶尔会尝试灰度部署。灰度部署可能对于互联网类型的大流量高并发的应用更有意义,因为它们会涉及到更多的资源,灰度发布会更节省资源。

    我理解金丝雀发布这种方式并不会和某种应用类型绑定,之所以在Web应用中流行,是因为对于用户来说,Web类型的应用,只需要在用户端安装浏览器即可,不需要有额外的配置,所有的安装部署全部在服务器端进行,更容易控制。

    如果在移动端或者桌面端实施这一部署方式,需要1. 筛选种子用户,发送版本更新消息,并提供更新途径。2. 用户更新版本后,收集用户使用情况,评估新版本是否达到预期目标。3. 根据评估结果,决定是否升级版本或者回滚。

    种子用户的维护比较重要,一般会先从内部用户开始逐渐扩展。

    无论哪种类型的应用,采用金丝雀的方式进行部署,都会对监控提出更高的要求。

    作者回复: @日拱一卒 同学,每一次的回答都很到位。先赞一个!

    这里稍微补充一点。在移动端进行金丝雀发布还是比较普遍的。因为很多移动端APP。都是强依赖一个后端服务。可以比较方便的通过后端API来进行控制。如果是桌面版的程序,要实现金丝雀发布,前提也是需要有一个和后端服务沟通的渠道。

    这里的一个技巧,是使用功能开关来控制版本的回归,而不用要求客户重新安装旧版本。

    2019-10-02
    1
    2
  • 幻想
    这篇是这个专栏里的精品文章,写的很好,优秀。
    2019-12-08
  • lisa
    在生产环境下做集成测试提到了两个方法对于写用例的成本太高了,尤其是测试同学来写集成用例,因为涉及到和被测系统的联动,比如识别测试标签,识别后可能会根据测试点需要做不同的处理,感觉很难落地,facebook在这块落地上有遇到什么困难,怎么解决的,可以详细说说么?

    作者回复: 我在Facebook工作的时候,Facebook没有怎么使用在生产环境下做集成测试。大家很多集成测试是在开发环境和测试环境直接做的。不过因为开发环境、测试环境和生产环境共享数据,所以集成测试跟线上环境还是很相似。这里有一个做法可以参考,对对测试数据打标签、所有业务逻辑都对测试标签进行处理。所以我觉得"识别后可能会根据测试点需要做不同的处理"这个就得这么做。

    2019-10-07
收起评论
3
返回
顶部