引自一个工程师的博客，来源已不详，感谢
中国雅虎的开发流程沿袭了 Yahoo 的开发流程，乍看之下很平常，对于已经熟悉的工程师来说还显得枯燥，但后来我特别留心了这套流程之后，非常惊奇于它的严谨和高效，所以这里要详细说明一 下。Yahoo 的内部生产线分为三个相互独立的环境：开发环境、测试环境和生产环境（即线上环境）。这三个环境虽然独立，但它们的配置都会尽量保持一致，这样就可以保证 开发完成的产品不会因为环境不同而出现问题。在开发的时候，我们会在开发环境中搭建虚拟环境，开发完毕之后开发工程师会自己在虚拟环境里面测试，保证没有 大的问题，然后就会把所有相关文件打包上传到雅虎全球统一放置产品包的地方。上传完毕之后，就会发邮件通知 QA 部门相关人员，邮件内容里面要写明产品在测试环境的部署步骤：需要安装哪些包、是否需要修改数据库等等。然后 QA 就会开始测试，如果发现 BUG 就会写到 Bugzilla 中，指派给相应的开发工程师，开发工程师就会在开发环境中定位BUG并修正，修正一些BUG之后就会再次打包升级产品的版本，然后QA 会将新的软件包部署到测试环境验证之前的 BUG 并报告新的 BUG 。整个测试过程中可能要发布好多个版本，直到所有 BUG 被修正为止。修正完毕所有的 BUG 之后，开发工程师就会填写上线申请，Ops 看到申请之后就会安排一个时间把产品部署到生产环境。一般来说，生产环境不止会有一台机器，所以 Ops 会先从生产环境摘下一台机器部署，部署完毕之后会告知 QA 和开发工程师，然后 QA 和开发工程师就会修改 Hosts 文件，配置域名指向那台机器进行线上的测试，如果测试没有问题，那么就会把软件包部署到生产环境中所有的机器上，完成上线；否则就进行回滚，取消这次上 线，也不会影响到线上的用户。

整个流程大概就是这样，但是要特别注意的是以下几点：1. 开发工程师只能接触开发环境。他所能做的就是在开发环境中开发、改 BUG 和打包上传。如果他去测试环境中修改 BUG，就很有可能忘记修改开发环境中的相应代码，这可能会导致产品测试通过但是上线之后却发现大的问题。 2. 产品“封版”之后就不可以做任何改动，如果有改动，即使只改动了一点所有功能也要重新测试一遍。所有的 BUG 都修改完毕之后的那个版本就会进行“封版”，那就标志着这个产品随时可以准备上线了。如果真的发现了新的 BUG 要修改的话，那么修改之后就需要重新打包重新走一遍完整的测试流程，只有这样才能够保证就算修改代码过程中引入了新的 BUG 也不会被遗漏。 3. 上线手册要详细。开发工程师要详细写明每一个步骤，不只是说明性的文字，还要把具体的安装和修改命令完整地放上去，如果写得好的话，那么 Ops 的同事只需要把上线手册里面的命令逐行复制到服务器上运行就可以完成上线。

这样的流程有什么好处呢？ 首先，它最大地降低了上线风险。因为开发工程师不能接触到测试环境，只能打包让QA测试，所以完整经过测试的产品上线之后基本不会有什么问题，况且上线的 时候我们也要先部署到一台机器上进行测试之后才会决定是否上线，即使上线不成功也可以在不影响用户的情况下回滚。中国雅虎的上线极少会出现问题，很多时候 我们上线到半夜只是因为那个时间段用户访问量最小，而不是说焦头烂额地忙活几个小时一直到半夜才上线成功。其次，它使得各个部门职责分明。开发工程师和 QA 通过 Bugzilla 沟通，和 Ops 通过上线手册沟通，因为沟通渠道唯一而且清晰，所以就可以完全责任到人，出了问题也很容易定位到具体环节。比如说，如果产品测试通过之后在上线的时候出现 了问题，那么基本就可以确定是 Ops 操作失误或者上线手册没有写好。职责分明之后很多事情也变得有条理，大家就可以各司其职、专注本职工作并且合作愉快，开会的时候也可以明确知道需要哪些人 参加。

完善、清晰的流程从根本上解决了一些问题，创建了一个非常好的环境，这样我们就可以把心思都放在如何开发和测试上面，而不用担心诸如“如何上线才能 不出错”等琐碎的事情。所以尽管中国雅虎的高层那么不靠谱，我工作得还是很开心，因为这个流程保证了管理层再怎么乱开发也不会乱。记得那时候很喜欢改 BUG ，有时候改得兴起会把之前版本遗留的 miss BUG 一并改掉，加班也是颇有兴致，不是很能明白为什么网上大部分程序员讨厌加班讨厌得要死。现在我明白了。