Martin Fowler 的持续集成(5)

　　持续集成并不能消除bug，却能帮你快速的发现bug并予以清除。这种情况下，持续集成更像是自测试的代码。当遇到bug时，由于你只做了很小的修改，这样便大大缩小的bug的查找范围。另外，由于是你刚写的代码，你还记得很清楚，因此也使查找bug更加容易。你还可以使用diff debugging，将当前的代码版本和先前没有bug的版本进行比较。

　　Bug也存在积累性，bug越多，越难清除。部分原因在于bug之间存在牵连。另外也存在心理因素，bug一多，人便没那么多精力去修了——这就是所谓的“Broken Windows 综合征”。

　　因此，对于采用持续集成的团队，bug将大大减少，不管是在生产环境，还是在开发环境。但是，我想强调的是，你的获益程度取决于测试的好坏程度。你或许已发现，写出好多测试并不难。然而，要达到低bug率的程度依然是需要时间的，你还得不断地引入并改进自己的测试。

　　有了持续集成，频繁部署也不是什么难事了。频繁部署的价值在于，你的客户可以快速的享用软件的新功能，并能快速的提出反馈。这将有利于清除客户和开发之间的障碍——我认为这是软件开发最大的障碍。

　　引入持续集成

　　然后你开始试着玩持续集成了，但该从何入手呢?上文中我所罗列持续集成实践可以给你带来太多的好处，但是你并不必在一开始就完全采用这些实践的。

　　做持续集成没有套路，主要取决于你团队自身的情况，但是我们发现以下几点对于持续集成来说是比较通用的。

　　(1)第一步需要将构建自动化，并将你所需的所有东西都放在代码管理系统中，以至于可以通过一个命令来构建整个系统。对很多项目来说，这并非易事。一开始，你可以按照需要进行构建，或者可以只做自动化的夜晚构建。虽然，这些做法都不能称为持续集成，但夜晚构建确是一个好的起点。

　　(2)在构建中引入一些自动化测试，试着确定出现问题的主要范围，并用自动化测试去发现这些问题。对于已有的项目来说，很难建立起一组好的快速测试，这时你就得另寻它路了。

　　(3)使提交构建快速完成。虽然好几个小时的持续集成比没有要好，但是如果你能将构建时间缩短到几十分钟，或者就短短的10分钟，这就再好不过了。

　　(4)对于新项目，从项目开始就采用持续集成。注意构建时间，如果构建时间违背了“10分钟原则”，那么请尽快采取行动。

　　(5)寻找帮助，找有经验的人帮助你。和其它的新技术一样，当不知到结果会是什么样时，很难开头。找一个导师可能要花钱，但是不找的话，你所付出的代价是时间的浪费和低下的生产力。(ThoughtWorks提供这样的咨询服务，毕竟你可能遇到的问题我们之前都遇到过。)

　　总结

　　自Matt和我发布了本文的第一版之后，持续集成逐渐变成了软件开发的主流技术，在ThoughtWorks，几乎所有的项目都使用到持续集成，同时我们也看到世界上其他组织也在使用持续集成技术。相比起充满争议的极限编程来说，持续集成很少得到负面的评论。

　　如果你还没有采用持续集成，我强烈建议你试一试。如果你已经采用了持续集成，本文可能会帮助你进一步提高效率。这些年来，我们已经学到了许多关于持续集成的知识，我们也希望有更多可以学习和改进的地方。

　　延伸阅读

　　像本文这样的文章通常只能涵盖一些基本，但它却是一种重要的话题，所以我在自己网站上放了一个guide page，那里你可以获得更多的信息。

原文转自：http://www.ltesting.net