来自Facebook的大规模持续交付实践

译者：乐视SCM高翻院 罗汉彬

前言

随着时间的推移，软件行业已经发展出了多种快速、安全地交付高质量代码的方法，主要集中在持续集成、持续交付，敏捷开发，DevOps 和测试驱动开发等方向。 

所有这些方法都有一个共同的目标：使开发人员能以安全、小批量、增量的方式提供正确的代码，以便向用户快速交付服务。

在Facebook的开发和部署流程的持续发展中，使用了多种快速迭代技术，并不拘泥于某一种。 这种灵活、实用的方式使我们能够在快速迭代周期中成功地发布我们的网站和移动产品。

多年来，我们使用简单的主干/发布分支策略，每天对前后端代码进行三次推送合入。 该策略要求工程师每天从代码主线中拣选已通过一系列自动化测试的提交，合入到从主干分支拉出的发布分支中。

通常，我们每天会有500-700 个代码拣选（cherry-pick）。每周，我们会从从主线重新拉出一个发布分支，然后拣选本周所有未被拣选的新提交。 

发布系统的规模越来越大，从2007年的几个工程师到今天的数千人。 好消息是，随着更多工程师加入，团队规模扩大，我们也完成了更多的工作。

但是，除了工具和自动化系统外，还有相当多的发布工程师人力投入，以保障每天和每周代码发布工作。

我们意识到，如果交付更多代码需要更多的发布工程师，代码交付将变得不可持续。

到2016年，我们发现分支拣选模式已经达到它的极限。我们每天有超过 1000 个代码修改提交合入到代码主线，每周合入数量有时多达 10000 个。要协调每周交付如此大量代码的人力，变得不可持续。

2016年4月，我们决定将Facebook主站（facebook.com）迁移到一个准持续的"主线发布"系统。一年内，我们首先覆盖了50%的开发人员，然后针对生产环境，从0.1%到1%，再切换到10%的生产环境网站流量。

随着发布系统的发展，便于我们验证工具的能力，以及控制不断增长的发布频率，并获得真实的反馈。我们的核心目标是新系统能使人们有更好的体验 - 最起码不能变得更糟。

按照这个方针，经过一年的规划和开发，在2017年4月，我们实现了通过发布系统，对所有产品直接从主线进行代码交付发布。

规模化持续交付

真正的持续交付系统能将每一个有效代码变更快速的发布到生产环境，在Facebook，高速的代码修改提交，要求我们开发一个每隔几小时就能发布数十到数百的代码变更的系统。

在这种准持续交付模式下，代码变更通常是小型并增量的，几乎不会对用户实际体验产生明显影响。每个发布在几小时内以分级的方式推出到100%的生产环境，这样我们可以在遇到任何问题时停止推送。 首先，代码修改在经过一系列内部自动化测试并被合入到代码主线后，将会推送发布给Facebook内部员工。 在这个阶段，一旦我们的回归发现问题，我们会收到发布阻塞警报，一个紧急停止按钮能让我们停止继续发布。

当一切正常，即将代码修改提交到 2%的生产环境，再次收集反馈和监控报警，特别关注我们在测试或者员工验证阶段无法覆盖的案例。最后，将代码修改发布到100%生产环境，在这个正式用户环境中，我们的 Flytrap 工具汇总用户的报告，并提醒我们任何异常现象。

许多变更在最初阶段就被我们的门禁系统拒之门外，这使我们能独立于新功能发布移动应用和网站代码，有助于降低代码更新潜在风险。如果我们发现问题，我们可以简单地切换开关，而不是回滚到以前的版本或在后续修补。

这种准持续周期发布具有以下几个优点:

它消除了Hotfix的情况。在旧的每日 3 更的系统里，如果一个致命的的修改不得不修 45 33084 45 14986 0 0 1749 0 0:00:18 0:00:08 0:00:10 3093复，但又不在预定的发布计划，那么将不得不要求增加一个Hotfix发布。这种非计划发布是破坏性的，因为他们通常需要人手动操作，并可能和已有发布计划冲突。使用新发布系统，绝大多数需紧急修复致命问题，只需要简单合入到代码主线，就能在最近的一次发布中被修复。

它能更好的支持全球研发工程师团队。我们尝试计划 3 天一次发布，以适应我们全球各地的研发团队，但即便如此，要求全球各地工程师在统一的日期和时间进行代码发布，因为工程师们所在时区不同，导致同一时间发布变得不合适。新的准持续发布系统，意味全球各地工程师们，都可以发布代码，当它们认为修改有意义时。

它为公司扩大规模，提供了开发下一代工具、自动化系统及流程优化的能力。当我们从事这样的项目时，它在许多团队和系统中起到了压力测试的作用。我们改进了代码发布工具、代码检视工具、测试框架、能力管理系统、流量路由系统以及许多其他领域。希望项目能快速成功发布，是这些团队聚集在一起的原因之一。我们的改进将有助于确保为公司未来增长做好准备。。

带来更快更好的用户体验。当需要几天，或者几个星期，才能看见代码修改后的真实行为时，工程师们也许已经将注意力转移到其它事情上。使用持续交付系统，工程师们不必再等待一周或更长时间，就能获得他们代码修改反馈。他们能更快速的定位问题所在，并最快速度提供一个准备好的小型加固修改，而不是等待下一个大版本升级发布。从框架上，这个新系统提高我们对异常现象的响应速度。

最终，使工程师更贴近用户，提高产品开发能力和产品可靠性。

将持续交付应用到移动应用

在网站上使用准持续交付系统是可行的，一定程度上是因为我们拥有整个网站系统的控制权，并且可以构建或改进我们所需的工具。在移动平台上进行准持续交付，有更多挑战，因为现有大量的可用于移动平台的开发和部署工具，使得快速迭代变得困难。

致力于改善这一点，Facebook通过构建和开源大量的专门用于快速移动平台开发的工具，包括Nuclide，Buck，Phabricator，各种 iOS 库，React Native 和 Infer。这种构建和测试系统使我 们能够开发出可快速部署到移动平台的高质量代码。

我们的持续集成系统分为三个层次:构建，静态分析和测试。

每当开发人员将代码提交到移动应用主线，它将会在所有涉及的产品上进行构建。对于手机，这意味着每次代码提交，都会编译 Facebook、Messenger, Pages manager, Instagram 和其它应用。同时还会在不同的 Android 版本上进编译测试，确保能覆盖产品支持的所有芯片平台和模拟器。

在构建过程中，我们运行 linters 和静态分析工具 Infer。这些将有助于捕获空指针异常，资源和内存泄漏，未使用的变量和有不安全的系统调用，并将找出不符合脸谱编码规则的地方。

第三个并发系统，手机自动化测试，包括数千个单元测试，集成测试，以及由 Robolectric，XCTest，JUnit 和 WebDriver 等工具驱动的端到端测试。

这些构建和测试不仅在每次代码提交时运行，而且还可以在代码修改交付的整个周期内运行多次。 在 Android 上，我们每天有5到6万次之间构建发布。 通过将传统的持续交付技术应用于我们的移动系统，我们已经从四周发布转为两周发布，再到一 周发布。 现在，我们在移动设备上，还使用旧的网站主线/发布分支策略模型。

尽管我们每周只 发布一次，但是尽早在生产环境中进行测试依然重要，它能使我们的工程师尽可能快的获得修改 反馈。 我们每天为金丝雀用户提供移动发布应用，包括 100 万左右的 Android Beta 测试人员。 与此同时，我们增加了发布频率，我们的移动工程团队增长了 15 倍，我们的代码交付速度大大增加了。尽管如此，我们从 2012 到 2016 的数据显示，无论是推送的代码行还是推送的数量，Android 和 iOS 的工程师生产率都保持不变。

同样，不管发布的数量如何，移动发布所产生的 关键问题几乎都是恒定的，这表明我们的代码质量不会随着我们的规模持续扩大而受到影响。

有效工具和理论方法上巨大进步，这是配置管理领域工程师们激动人心时刻。我为脸谱网的团 队感到自豪，他们共同努力，为我提供了我认为是最先进的网站和移动设备大规模快速交付系统。使这一切成为可能的部分原因是拥有一个强大的，集中的发布工程团队，他们是基础工程 领域中佼佼者。

脸谱网的发布团队将继续推动改善开发人员和客户发布流程的举措，我们将继 续分享我们的经验、工具和最佳实践。

END

更多相关文章阅读

想了解中国银行 DevOps 历程，效果，及未来展望？

来 GOPS2017.上海站

中国银行软件中心质量工程师张新老师将带来精彩演讲

独乐乐不如众乐乐，DevOps 时代社区长期欢迎原创作者投稿，DevOps 时代社区愿陪伴您共同成长。投稿邮箱：[e-mail]

点击阅读原文关注GOPS2017.上海站活动官网