3年前，我在一个由20余人组成的产品团队开始了软件开发工作，随着项目规模的膨胀，某些bug重复出现， 延迟发布，团队熬夜工作，开发团队和测试团队关系紧张。难道软件开发只能如此？带着困惑，我加入了ThoughtWorks。在这里，进行开发是一件高效而有趣的事情。那么，是什么造成了两者间差别：

           X公司                ThoughtWorks
单元测试     JUnit                JUnit / JSUnit
功能测试     无                    JWebUnit
集成测试     人工                 Selenium
验收测试     人工                 Selenium
性能测试     Jmeter             Jmeter
集成         人工                CruiseControl

ThoughtWorks 的开发过程采取了更多自动化的开发方式。稳定而高效的开发效率保证了开发团队在一个轻松愉快的环境中工作，同时团队成员可以有更多的时间和精力学习新技术并将其应用在软件开发中。生产力的发展过程是不断采用物化劳动取代人自身的劳动的过程，是不断自动化的过程。自动化测试/集成将我们从简单，繁琐的低级脑力劳动中解放出来，从而进行更高层次的思考。这篇文章主要探讨如何在开发过程中使用自动化持续集成、使用持续集成工具的优势、以及如何通过持续集成工具管理产品的整个生命周期。

什么是持续集成？

持续集成一种软件开发实践。通过它，开发团队的成员频繁的整合他们之间的工作。它不是简单的组装软件而是软件开发过程的核心实践，通过时时运行测试，保证软件现有的功能不被破坏，自动分析现有代码的状态(有无重复逻辑，代码的复杂度等)并发布相关的报告。这些功能根据开发团队所采用的持续集成服务器不同而有所不同，如TeamCity 采用自动的服务器端分析，而开源项目CruiseControl要求开发团队采用Checkstyle， Emma， Simian 等代码分析工具。

持续集成的价值？

－ 减小风险

持续集成过程通常在开发人员提交代码后开始，服务器自动更新代码，编译，运行单元测试，功能测试，集成测试，进行部署。这个持续集成的过程可以帮助开发人员快速发现并解决问题(编译失败，测试失败等)。与开发人员的机器相比，持续集成服务器运行在相对稳定、干净的环境中(减小跟踪调试的难度)，持续集成过程的失败通常意味着近一次更新破坏了软件现有功能或引入了新的缺陷。在持续集成过程结束后，除了构建结果(War， Jar等)，通常会生成代码分析报告(测试覆盖率等)，帮助项目管理人员更好的了解并改善项目。

－ 减少手动过程

在开发过程中大量的采取手动过程不仅降低了团队的生产率，更严重的是它将许多不确定的因素引入到产品的构建过程中，这使得发现以及解决问题变得异常困难。 QA在测试环境中所发现的问题可能是由于部署人员忘记拷贝某个配置文件，也可能是由于没有删除某些临时文件引起的。通过使用持续集成工具将构建过程自动化，便于分析并找出问题，大大提高了团队的效率。

－ 生成构建结果

从客户和用户的角度看，一个可以部署或者执行的构建产物才是重要的。在使用持续集成工具的环境中，开发人员对源文件进行修改，提交，持续集成服务器会将这部分修改与其他的代码进行整合，测试，并重新生成终产品(War， Jar， exe等)。如果在其中任何一个环节出现了问题，相关人员可以很快的得到反馈。在没有使用持续集成工具的环境中，大量的问题只有在产品发布前进行终集成的时候才会出现，开发团队往往在发布前承受着巨大的压力，并导致产品延迟发布或者在进行hot fix的过程中引入更多、更严重的缺陷。

－ 安全感

软件开发过程终表现为人与人之间各种形式的合作。安全感与信心是合作基础也是重要的部分。通过使用持续集成工具，开发人员可以了解到新的代码是否引入了缺陷，管理人员可以通过使用各种形式的报告对项目进行评估。不断发布的构建结果，使测试人员得以自始至终的参与到整个开发过程中，而不是在软件开发的后阶段才加入团队。

如何进行持续集成？

在进行持续集成实践前，应当正确的选择并配置持续集成服务器。列出了所有的持续集成服务器 ，其中比较成熟的持续集成服务器包括：CruiseControl， Anthill， Bamboo， TeamCity， Continuum 等。CruiseControl作为开源产品，以其对于各种SCM以及构建工具的广泛支持而被许多开发团队所接受。

在一个典型的持续集成过程中：

－ 开发者每次将代码提交到SVN之前，必须运行本地测试： 尽量保证不会破坏持续集成服务器的构建过程。

－ 开发者每天进行多次提交：小步前进会大大减少服务器构建失败的概率，并且使得修复失败构建的时间大大缩短。

－ 持续集成在一台服务器上不断运行：保证在稳定的环境中进行测试。

－ 所有的测试必须全部通过：保证软件现有的功能不被破坏并且没有引入新的缺陷

－ 生成构建结果(War， Jar，exe等) ： 用以开展下一步的工作，譬如QA的探索测试等。

－ 生成报表 ：帮助管理人员评估开发状态。

－ 修复失败的构建 ： 失败的构建意味着软件现有的功能已经被破坏或者有新的缺陷被引入，修复的速度越慢使修复难度越高，并带来更大的损失。

持续集成坏味道：

－ 持续编译

［现象］某些团队仅仅使用持续集成服务进行编译并生成终的构建结果。
［影响］持续集成无法给开发人员，管理人员带来有价值的快速反馈。
［原因］开发团队可能缺乏编写易于测试的代码的能力，或者不了解现代软件开发中测试的流程和作用
［解决方案］测试优先，单元测试，功能测试，验收测试
－ 构建长时间失败

［现象］ 没有开发者愿意修复失败的构建，持续集成工具上的构建已经持续失败很长时间。
［影响］ 开发者忽视持续集成服务器发布的结果，修复构建的成本和难度升高，开发团队，管理团队无法得到快速反馈，丧失安全感
[原因] 长时间不进行代码更新并一次提交太多代码，构建时间太长导致开发者缺乏耐心运行本地构建、任务过于复杂
[解决方案] 简单设计，小步前进，缩短构建时间
－ 过多失败构建