Facebook 是如何进行大规模代码部署的

Facebook 高速发展的 2007 年到 2016 年,他们一天部署 3 次代码,cherry-pick 集齐成千上万个 commit;现在使用类似持续交付的方法,每个 commit 能自动部署到 production。公司里有很多员工、很多用户的好处:新代码让公司所有员工先用上,因为员工数足够多,能很快发现问题;然后让 2% 的访问量用上新代码,最后慢慢增加到 100% 的访问量。

不久前有篇关于缩短 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 的工具收集用户报告,并发送任何异常情况的告警。

(adsbygoogle = window.adsbygoogle || []).push({});

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

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

• 构建:合并到移动主分支上的所有代码都会进行构建,这会针对受影响的所有产品(Instagram、Messenger)并且会跨各种芯片架构。

• 静态代码分析:Linters 和静态分析工具的组合,称为 Infer ,用于检查各种问题,包括资源泄漏、未使用的变量、有风险的系统调用和编码准则违规。

• 自动测试:包括单元、集成和端到端测试,会使用到 Roboelectric、XCTest、JUnit 和 WebDriver 等工具。

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

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

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

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏云计算D1net

如何构建一个更好的云安全模型

公共云的自助服务提供模式带来了许多好处,但当然也破坏了传统的IT服务器配置模式。现在,开发人员可以通过信用卡自行分配资源,企业安全团队也为他们的工作做了切实的工...

3738
来自专栏魏琼东

DotNET企业架构应用实践-系统架构与性能-理论依据及相关技术

性能优化介绍       在企业应用开发领域,企业架构与性能将会是一个恒久的话题,如何提高性能、性能优化也将是一个长期和不断改进的过程,有人在硬件投入上下功夫、...

2006
来自专栏云计算D1net

如何集成云层与本地存储

云和本地存储正走向越来越紧密的整合,于是云成为了另一个存储管理员可用的层级。 ? 组织不大可能把100%的数据都移到云服务上,但大多数企业都会至少想让一部分数据...

3146
来自专栏程序你好

设计一个成功的API程序的10条法则

早在上世纪90年代中后期,互联网是一个奇怪的、但不断增长的生态系统。企业意识到了这种潜力,一些企业实际上知道如何利用这种潜力。然而,人人都知道的一件事是,上网是...

692
来自专栏TEG云端专业号的专栏

裴泽良:海量存储与CDN的自动化运维

架构平台部提供的服务大家都使用过,微信QQ聊天的图片,朋友圈图片,QQ音乐里面的歌曲,腾讯游戏,应用宝里面的app的下载,腾讯云的COS对象存储,点播,直播,以...

7.5K7
来自专栏数据和云

加速Oracle RAC性能 软件定义存储的数据库云化实践

简介: 刘振宇 云和恩墨基础架构软件研发负责人。 拥有10年以上电信、金融、保险、政府机关以及制造业等多个行业的架构和管理经验。现在负责云和恩墨软件定义存储zD...

3724
来自专栏腾讯大数据的专栏

一行代码,一个系统!您的 Crash 实时分析已上线

腾讯移动分析(MTA),将内部打磨多年的 Crash分析能力对外输出,在复杂的App生态下,专注于构建完善的质量体系,助力 App 研发者用一行代码拥有完整 C...

3311
来自专栏腾讯移动品质中心TMQ的专栏

腾讯TMQ在线沙龙|腾讯手机管家iOS测试实战

腾讯手机管家iOS测试实战 活动时间:2016年11月10日 QQ群视频交流 活动介绍:TMQ在线沙龙第十二期分享 本次分享的主题是老司机给大家分享腾讯手机管家...

2685
来自专栏新智元

【干货】谷歌软件工程技术实践总结:软件开发、管理和人员调配(20PDF)

【新智元导读】作者 Fergus Henderson已在Google工作了10年以上,拥有超过15年的商业类软件的行业经验。本文梳理并介绍了Google 软件开...

4187
来自专栏腾讯高校合作

小程序这13大新能力,将对你产生什么影响?

微信公开课“小程序专场”,微信团队带来两项全新能力——“第三方服务”和“附近的小程序”。 至此,小程序近期一共开放了13项新能力。对于用户来讲,会带来哪些影响呢...

3366

扫码关注云+社区

领取腾讯云代金券