Debian.cn
Debian中文资讯站

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 的工具收集用户报告,并发送任何异常情况的告警。

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

未经允许不得转载:Debian.cn » Facebook 是如何进行大规模代码部署的

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址