Facebook是世界上最大的社交网站，有超过10亿用户每月至少要登录一次，他们每天要上传超过25亿内容，支持这样一个站点的运行，还要不断发布新的功能，Facebook的工程师是如何做到这一切的？目前就职于Facebook的极限编程创始人Kent Beck在近期发表的一篇与别人合著的论文里向大家详细介绍了Facebook的开发与部署流程。
显而易见，Facebook的工程师们不会像传统软件行业那样使用瀑布模型进行开发，他们不断地开发新的功能，并迅速上线，让用户能够访问到这些新功能，这就是大家口中经常提到的持续部署（continuous deployment）。在他们看来，Facebook的开发永远没有到头的那一天，代码库在不停地增长着，目前已经有超过1000万行代码，其中850万是PHP代码，代码随时间呈现超线性增长的趋势。 在Facebook，所有前端工程师都工作在同一个稳定的分支上，这也能加快开发速度，因为省去了繁琐的分支合并过程。在日常开发中，每个人都用git在本地进行开发，当代码就绪之后，就会将它推送到SVN上（之所以是SVN，这是出于历史原因），这样就很自然地区分开了开发中的代码和可以上线的代码。 但是为了保证网站的稳定运行，并非是工程师将代码推送到SVN上，认为可以上线，代码就能发布上线的。Facebook采用了一种兼顾了速度与稳定性的做法——将每日发布与每周发布结合到一起。所有的代码变动默认是每周发布，每次发布会包含相对比较多的变更，在每周日的下午，代码会被发布工程师推送到SVN上，随后会进行大量的自动测试，其中包含很多针对正确性和性能的回归测试，这个版本会成为Facebook员工内部使用的默认版本，正式的发布通常被安排在周二下午。 发布工程师会为每个工程师的历史表现打分，内部称为“Push Karma”，比如那些代码经常出问题的人，分数就会相对较低，他们的代码自然也会受到更多的“关照”。这样做的目的是控制发布的风险，而非对某人做出评判，因此这个分数是保密的。除此之外，越是大的变更，或者在Code Review时讨论越是多的代码，也是风险较高的地方，同样会受到更多的“关照”。 在每周发布以外，其他工作日每天会有两次小发布，大多是些非关键性的更新，或者是些Bugfix，极端情况下会进行更多的发布，甚至是在周末进行发布。 在被纳入发布之前，代码已经经过了开发者的单元测试和Code Review，在Facebook，Code Review是非常重要的事情，他们使用名为Phabricator的工具进行Code Reivew，该工具是和代码版本管理整合在一起的。 在大量的自动化测试之外，每位员工在内部使用Facebook时也相当于进行了高密度的测试，每位员工都能报告自己发现的问题，写代码的人多了，代码增长的快了，相对而言，对代码进行测试的人也多了。 在性能方面，Facebook使用Perflab对新老代码的性能进行对比，如果新的代码性能不理想，并且开发工程师无法及时修复，那么相关代码就会从本次发布中剔除出去，待问题修复后再进行发布。每个小的性能问题都是不容忽视的，因为小问题会很快累积起来，变成影响容量和性能的大问题，Perflab能通过图表的形式直观地展现系统的性能。 |
