[关闭]
@sambodhi 2017-09-27T22:29:43.000000Z 字数 1871 阅读 2111

Facebook 如何实现大规模快速发布

摘要:

不久前有篇关于 Facebook 发布流程的文章,阐述了将 Web 和移动 App 巨大数量的代码变更投入生产的灵活方法。这篇文章着重讲述了他们在一年之内如何从“ cherry-picking ”升级到“ push-from-master ”策略,以及他们为实现这一目标所用到的工具和方法。

正文:

不久前有篇关于缩短 Facebook 发布流程的文章,阐述了将代码投入生产的灵活方法。这篇文章着重讲述了他们在一年之内如何从“ cherry-picking ”升级到“ push-from-master ”策略。早些时候, Facebook 分享了他们部署过程的细节。作者 Chuck Rossi 是 Facebook 的首位发布工程师,目前是 Facebook 发布工程的工程总监。

Facebook 的发布周期是“ quasi-continuous ” (准连续)——这只是一种委婉的说法,表明并非每次提交都会部署到生产环境,实际上它采用的是对几十到几百个提交进行批处理,每隔几个小时就进行推送。这种分层发布的方式使任何变更的回滚很容易。

这个新系统从 2016 年 4 月开始,经过一年的时间慢慢地完善。早先的模式是从主干分支的提交中选择特定的变更放到发布分支上。发布分支每天将这些变更推送到生产环境。这种“ cherry-picking ”的特点是,每天选择变更的数量为 500 ~ 1000。剩下的变更就推入到每周发布分支中。随着时间的推移,提交的数量和参与其中的工程师都有所增加,发布工程师的手工劳动变得过多,以至于无法持续。

这个 CD 系统的关键组件是一种控制方法,即谁将接收变更,以及用于部署和测量的自动化工具。在第一步中,经过一系列自动化测试后,变更就从内部推送到 Facebook 员工。在这一阶段发现的任何回归,都会被认为这一进程受阻或者停止。下一步涉及到“ canary deployment ”(金丝雀部署),只推送至生产环境的 2% 。依靠连续的监测来检测问题。如果一切顺利,这些变更将 100% 部署到生产环境中。名为 Flytrap 的工具收集用户报告,并发送任何异常情况的告警。


图片来自:https://code.facebook.com/posts/270314900139291/rapid-release-at-massive-scale

Facebook 中的 Web 和移动产品遵循两条不同的路径,原生移动变更的部署频率低于 Web 。这两个都由名为 Gatekeeper 的系统控制。除此之外,Gatekeeper 还分离出了部署和发布。这种分离带来了挑战,包括维护向下兼容性

由于工具和部署选项的性质,移动持续部署面临着一些特定的挑战。Web 部署则更为容易,因为 Facebook 拥有完整的技术栈和工具。为了解决这些挑战,Facebook 已经构建了一些专注于更快的移动开发的工具和库,包括 BuckPhabricatorInferReact 以及 Nuclide 。Facebook 的移动部署是以三层来并发运行。

在代码变更的生命周期内,每次提交都会执行移动构建并运行测试栈,这样就会运行很多次。单单 Android 一天就有 5 万到 6 万个构建版本。移动部署系统遵循较早的基于 Web 的模式,每周发布一次,按 cherry-picking 策略随机选择变更。尽管代码传输速度和发布频率有所增长,但工程师的生产率保持不变。然而,本文提到的标准(代码行和推送次数),可能并非衡量生产率的最佳标准。

2016 年 IEEE 的论文相关讨论,Facebook 早在 2005 年就利用了某种形式的 CD。该论文中的一些结论列出了 CD 成功的先决条件:可观的持续投资、高度熟练的开发人员、强大的技术管理,开放和平等的文化,风险回报权衡管理、客观回顾失败以及有专注力的小团队。

Facebook 的准连续部署系统具备这几个优点:没有推送热补丁的手工开销,对分布式工程师团队有更好的支持,为工程师提供了更快的反馈循环。

查看英文原文:How Facebook Achieves Rapid Release at Massive Scale

添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注