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