持续集成理论和实践的新进展.docxVIP

持续集成理论和实践的新进展　最近雷镇同学将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　第二版相对于第一版增加了不少内容，其中最重要的几点包括：详细介绍了使用持续集成进行软件开发的工作流程。突出了配置管理在持续集成实践中的作用。提出分阶段构建的概念。增加了持续集成报告的内容。增加了持续部署的内容。给出了引入持续集成的建议。　持续集成的流程　在持续集成领域，我们经常会用到的一个术语就是“构建（Build）”。很多人认为“构建=编译+链接（Build=Compile+Link）”，Martin在第一版中指出一次成功构建包括：所有最新代码从配置管理工具中取出（check out或者update）。所有的代码从干净的状态开始编译。将编译结果链接并部署，以备执行。执行部署的应用并运行测试套。如果上述所有操作没有任何错误，没有人工干预，并通过了所有测试，我们认为这才是一次成功的构建。　实际上，目前很多团队对成功持续集成构建的定义基本上是符合上述定义的。这个定义的特点在于它是相对独立的，它是一个从干净状态的源代码最终获得可运行的通过验证的软件的过程。　Martin在第二版中则在成功构建的基础上给出了成功集成的定义。成功集成关注的不是一次“编译+链接+部署+验证”的过程，而是从开发流程的角度介绍一次完整的在持续集成约束下的代码提交过程4：将已集成的源代码复制一份到本地计算机。修改产品代码和添加修改自动化测试。在自己的计算机上启动一个自动化构建。构建成功后，把别人的修改更新到我的工作拷贝中。再重新做构建。把修改提交到源码仓库。在集成计算机上并基于主线的代码再做一次构建。只有这次构建成功了，才说明改动被成功的集成了。　下图展示了Martin对成功集成的定义：　当然在第一版的“代码提交”这一节，Martin也提到了本地构建的概念，只是不如第二版这么明确。　配置管理　Martin在第一版中有两处提及配置管理，分别是：单一代码源（Single Source Point）和代码提交（Checking In）。第二版中则包括：通过持续集成构建特性（Building a Feature with Continuous Integration）、只维护一个代码仓库（Maintain a Single Source Repository）、每人每天都要向主线提交代码（Everyone Commi