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 的工程师文化才闻名遐迩于硅谷，并被国内引进加以学习。
评论