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