近雷镇同学将Martin Fowler先生的论文《持续集成》第二版翻译成中文并发布出来，掀起了国内对于持续集成理论和实践讨论的新的高潮。笔者在本文中将全面对比持续集成 论文前后两版的异同，分析并展示ThoughtWorks在持续集成领域的理论和实践方面的研究成果，以图对国内企业实施持续集成起到参考和借鉴作用。需 要说明的是，本文所介绍的内容毕竟限于笔者的水平，并且主要是ThoughtWorks内部开发和对外咨询实践的总结，所以未必对读者所遇到的情况是适用 的，请自行甄别。

　　《持续集成》第二版虽然是近才翻译出来，但是实际上Martin Fowler先生完成此文是在5年前的事情。这五年恰好是ThoughtWorks中国公司快速成长的五年。在这五年内ThoughtWorks中国在持 续集成领域也有很多的发展，这包括：的持续集成工具Cruise主要是由中国公司负责开发1; 中国公司帮助国内很多大中型企业完成持续集成实施和相关的流程改进;2009年中国公司的很多同事对于持续集成的度量进行了深入的讨论并且终由胡凯将其 实现为一款软件iAnalysis;2010年至2011年成功的交付了从需求提供方到多个技术服务提供商的持续集成方案，以及企业级自动化中心方案。所 以，本文主要包括两部分内容，一部分是通过对比第一版与第二版的异同介绍2000年到2006年之间持续集成领域的主要发展，另一部分则是介绍第二版发表 之后持续集成领域的新进展。读者如果之前没有阅读过《持续集成》论文的第二版，建议将本文第一部分一同阅读，因为本文并非对论文的重述，所以很多地方还需 要参考原文中的内容。

　　第一部分 《持续集成》第一版与第二版

　　《持续集成》第一版由ThoughtWorks首席科学家Martin Fowler先生和Matthew Foemmel共同完成2，第二版由Martin Fowler先生更新。

　　《持续集成》的第一版中并没有给出比较正式的定义，虽然作者在文中说是借鉴了XP实践中的术语，但是目前能看到的XP实践中对持续集成的定义实际上大多数都是指向了Martin的文章。那么我们还是来看看第二版中给出的定义。

　　持续集成是一种软件开发实践。在持续集成中，团队成员频繁集成他们的工作成果，一般每人每天至少集成一次，也可以多次。每次集成会经过自动构建(包 括自动测试)的验证，以尽快发现集成错误。许多团队发现这种方法可以显著减少集成引起的问题，并可以加快团队合作软件开发的速度。3

　　第二版相对于第一版增加了不少内容，其中重要的几点包括：

　　详细介绍了使用持续集成进行软件开发的工作流程。

　　突出了配置管理在持续集成实践中的作用。

　　提出分阶段构建的概念。

　　增加了持续集成报告的内容。

　　增加了持续部署的内容。

　　给出了引入持续集成的建议。

　　1) 持续集成的流程

　　在持续集成领域，我们经常会用到的一个术语是“构建(Build)”。很多人认为“构建=编译+链接(Build=Compile+Link)”，Martin在第一版中指出一次成功构建包括：

　　所有新代码从配置管理工具中取出(check out或者update)。

　　所有的代码从干净的状态开始编译。

　　将编译结果链接并部署，以备执行。

　　执行部署的应用并运行测试套。

　　如果上述所有操作没有任何错误，没有人工干预，并通过了所有测试，我们认为这才是一次成功的构建。

　　实际上，目前很多团队对成功持续集成构建的定义基本上是符合上述定义的。这个定义的特点在于它是相对独立的，它是一个从干净状态的源代码终获得可运行的通过验证的软件的过程。