揭秘 Facebook 的开发部署流程：数千名开发中没有一个测试

Facebook是全球最大的社交网站，今年一季度，Facebook 的月活已经达到 23.8 亿，日活 15.6 亿。这个惊人的用户体量规模是微信+QQ 的总和还要多。

以腾讯的海量服务之道为参考，很容易想到 Facebook 必然有一个规模庞大的工程技术团队，来支撑如此海量的业务需求。但实际上，Facebook 的工程团队只有数千名工程师，在很长一段时间内，该公司甚至只有个位数的发布工程师，并且没有测试工程师！

Facebook 的开发部署流程究竟有何与众不同，可以让其效率如此惊人？

持续部署

传统软件行业通常使用瀑布式开发模型，但这种开发模式对于 Facebook 的业务增长规模显然是不适用的。Facebook 与其他大型互联网公司一样，采用的是持续部署的开发模式：不断开发新的功能，迅速上线，满足用户需求。

Facebook 的工程团队认为，他们的开发工作永远没有到头的那一天，代码库的增长永不停止，2013 年时就有超过 1000 万行代码（850 万 PHP 代码），而到 2019 年时，其代码库已经突破一亿行。

Facebook 的所有前端都在同一个稳定分支上工作，这样做的好处是能加快开发速度，因为省去了繁琐的分支合并过程。在日常工作中，工程师都用 git 在本地进行开发，当代码就绪之后再将它推送到 SVN 上，这样就很自然地区分开了开发中的代码和可以上线的代码。

每日、每周发布相结合

工程师将代码推送到SVN上，就可以上线了吗？并不是。Facebook 为了保证网站的稳定运行，采用了一种兼顾稳定性与速度的做法：将每日发布与每周发布结合到一起。

所有代码变动默认每周发布，每次包含相对比较多的变更。每周固定时间，代码会被发布工程师推送到 SVN 上进行大量的自动测试，其中包含很多针对正确性和性能的回归测试，这个版本会成为内部使用的默认版本，正式的发布通常被安排在周二下午。

在每周发布以外，其他工作日每天还会有两次小型的发布，通常是些非关键性的更新，或者是 Bugfix，极端情况下才会进行更多的发布，甚至是在周末进行发布。

没有测试工程师

Facebook 是一个没有专门测试工程师的科技公司，该公司的所有测试工作都交由自动测试和开发团队自己。

代码上线前，除了进行大量自动化测试之外，每位工程师在内部使用 Facebook 时也相当于进行了高密度的内测，每位工程师都能报告自己发现的问题，写代码的人多了，代码增长得快了，相对而言，对代码进行测试的人也多了。

代码质量如何保证

Facebook 有一个名叫“Push Karma”的机制。这个机制是指：Facebook 的发布工程师会对每个提交代码工程师的历史表现打分，那些经常出 bug 的工程师相应得分也会比较低，因此他们提交的代码会受到更多的“关注”。

这样做的目的是为了控制风险，而非对个人做出评判，因此这个分数是保密的，工程师不会知道自己的分数是高是低。

除此以外，比较大型或相对重要的发布、Code Review 时讨论较多的代码，都是风险比较高的地方，也会受到更多的“关注”。

Facebook 除了细致的 Code Review 以外，还有一个很有特色的“Zuck Review”。一些比较大的功能或产品，扎克伯格会亲自看一下，只要团队 PM 亲自跟扎克伯格说，这个地方你要过一遍，即使再忙他都会亲自来盯。

发布分阶段

类似于 Facebook 的大型网站，发布通常都是分阶段进行的：

• H1：部署到仅有内部访问的服务器上，进行最后的测试，也就是“预发布”；

• H2：部署到几千台服务器上，灰度开放给一小部分用户；

• H3：如果 H2 阶段没有发现问题，则进入 H3，部署到全部服务器上。

如果在这个过程中发现问题，工程师会立即进行修复，随后重新开始分阶段的部署。当然，也可以选择回滚代码，具体视情况而定。

工程师文化是关键

仅有方法论和工具是远远不够的，因为使用它的是人，而人总是会犯错。所以，拥有鼓励个人责任感的企业文化是很重要的。

Facebook 的每位工程师都可以看到全部的代码，并且能提交补丁，或者提交详细的问题描述。工程师们需要自己编写详尽的单元测试，他们的代码还要通过所有的回归测试，并能支持后续的各种运维工作。

除了要对自己的代码负责，他们还要面对各种巨大的挑战，往往要针对多种解决方案进行大量试验。

Facebook 还有一个新兵训练营制度，让那些新入职的工程师，甚至包括不主要从事编程工作的经理都去学习他们的代码、工具和方法。训练的目的很多，其中之一就是让新员工充分认识到，他们拥有直接改变 Facebook 网站的力量。

在这样的氛围下，Facebook 的工程师文化才闻名遐迩于硅谷，并被国内引进加以学习。