每个开发过软件的人都能体会到，软件开发绝非一帆风顺，每个人开发出来的代码绝对不会魔术般的自己组合在一起，当新的功能加入到原有软件中的时候，往往不小心破坏了原有的功能，引入了一些bug，当老的bug被修复的时候，又往往会导致其他bug的产生，更糟糕的是，这些bug往往在当时并不能及时被发现。当小组成员们完成了自己所负责的模块，等到最后来一起集成的时候，他们可能已经做好了修复集成问题的心理准备。所有的这一切，都是每个开发人员的切肤之痛。那么，问题到底出在哪了？
让我们不妨换一种思维，让我们不要停留在如何地去修复bug和集成过程中产生的问题，我们渴望的理想状况是，每当我们开发出新的代码并将他们加入原系统中的时候，如果我们能够被及时告知我们是否破坏了原有系统的功能，那么我就能够及时的作出反应，修复这些部分。如果这个过程的粒度足够的细、足够地频繁，我们就能期望每次新功能引入的时候所引起的破坏足够小，并且修复起来足够简单，如果每个开发人员都能够享受到如此的方便并且保证新加入的功能不会影响原有的功能，我们的整个软件过程就能够以一个稳步可靠的步伐，持续增量的向前行进，而不是不断地加入新的代码，然后等到后来bug被人发现的时候被动地去修复它。我想稳步可靠、持续增量的软件过程，是我们每个开发者心目中的理想过程。从开发者的角度来看，毕竟谁也不想经历那种当发现自己的修改破坏的原有的功能的时候的恼火的感受。
谈到这里，我想聪明的读者应该能够想到，刚才我们所说的就是前面最开始提到的持续集成。持续集成通俗地说就是持续地、频繁地进行集成，每当有新的修改加入的时候，修改的作者能够被及时地告知他的修改是否在引入新的功能的同时保证原有功能的完整。如果整个软件开发团队在一开始就采用这种方式，我们的软件就能被稳步可靠的构建起来。
讲到这里，读者们马上就会有疑问：“你说的只是一种理想状况罢了，谁都希望自己在加入新的代码的时候得知自己的代码是否破坏了原有的功能，但是怎么能够做到这一点，谁有能力来及时地告诉我们哪里有问题？持续集成这个想法不错，但怎么样能够做到持续集成？”我想这些问题是非常好也是关键的问题，持续集成究竟是否可行，如果可行，又该如何执行？我们这里不妨来整理一下，看看究竟什么是持续集成的难点。持续集成的难点主要在于，在新的功能加入的时候，如何来判断整个系统功能仍然完整；出错或者成功，谁来告诉我，如何告诉我；当大家一起协作的时候，如何保证每个人都能够准确地被告知而不会发生混乱。让我们来一个个地分析这些问题。
首先，确保真个系统功能完整性的手段就是测试，如果我们对所有的功能都有完整的测试，那么当新的功能引入的时候，如果某些原有的测试失败，就说明新的修改破坏了原有的功能，而失败的测试就能准确地告诉我们新的修改破坏了哪些原有的功能。其次，持续集成工具将告诉我们集成是否成功，持续集成工具通过运行整个系统中的测试，根据测试的结果来通知开发者，哪些测试失败导致的集成失败。每个软件项目通常会使用版本控制工具例如SVN、CVS，每当有开发者将新的修改加入到系统的代码库中时，持续集成工具会check out出代码库中的最新版本，使用自动化的构建工具例如Ant、Rake等，自动地编译项目中的代码、部署整个应用、准备测试所需的环境和数据、运行所有的测试包括单元测试、功能测试、集成测试等，在整个过程结束后将结果报告出来，持续集成工具会指出任何一个过程中出现的错误，并且准确地报告给开发者。在多人协作的情况下，版本控制工具确保了每个开发者的修改被正确有序地保存，当每个开发者想要提交自己的修改的之前，必须首先确保上一个人所提交的修改被成功集成，才能提交自己的代码，当确保自己的代码被正确集成之后，自己的工作才算完成，否则，就必须修复错误，再次提交，如此反复，直到被成功集成。
开源社区已经为我们提供了非常优秀的持续集成工具，CruiseControl、CruiseControl .Net已成为广泛使用而且非常成熟的持续集成工具，而持续集成所需要的自动化构建工具和版本管理工具如Ant、NAnt、SVN也已经是非常成熟。在下面，我尝试在我的使用经验的感受的基础上，挑选一些比较成熟或者很有潜力的工具，结合自己的使用经验，给大家做一些介绍。
我们先从持续集成的核心工具入手，这些工具在持续集成的整个过程扮演了类似于中央处理器的角色，它们负责更新每个开发人员提交的代码，使用构建工具自动运行所有的测试，然后调用其他工具将结果报告给开发人员。这一类的工具包括CruiseControl、CruiseControl .Net以及新兴的DamageControl等。
CruiseControl & CruiseControl .Net谈到持续集成工具就不能不谈谈CruiseControl（cruisecontrol.sourceforge.net），CruiseControl可谓持续集成工具中的龙头老大，也可以说是第一个成熟的开源持续集成工具。该工具由ThoughtWorks公司开发，并将其开源，同时提供了丰富的文档支持（http://confluence.public.thoughtworks.org/display/CC/Home）。
CruiseControl非常完美的实现了一个持续集成工具所需要具备的所有功能，它集成了包括SVN，CVS，VSS，StarTeam，ClearCase等在内的十几种版本管理工具，内建地支持了Ant，NAnt，Maven，Maven2等自动化构建工具，并且通过执行shell命令的方式间接支持几乎所有其他构建工具如make，jam等。你可以设置CruiseControl以多种方式运行系统的集成，既可以在每次有新的代码修改提交时自动运行，也可以让它定时运行。在运行完后，CruiseControl可用允许你使用各种方式报告运行的结果，包括发送电子邮件、使用ftp、rss、jabber、scp等工具报告结果，也可以让你自动化地在运行完后将整个系统打包、部署。它甚至允许你在运行完成后根据结果成功与否播放不同的音乐或电影，及时地告诉大家。
CruiseControl附带的web应用，用于报告每次的集成结果 在实际开发过程中，开发人员可以将CruiseControl配置为每次有新的修改时运行所有集成工作，这样当你提交你的修改以后，CruiseControl会自动地将代码库中的新的修改更新到一个事先指定的地方，然后按照你的配置准备测试数据、编译、运行系统中的所有测试。开发人员可以通过web方式通过CruiseControl附带的一个web程序查看运行的结果，这个结果页面会告诉大家该次build是否成功或失败，如果失败，大家也可以看到失败的错误信息，也可以告诉你在某一段时间之内所运行的集成的统计信息。根据配置，CruiseControl可以显示几乎集成过程中每个环节出现的错误，例如编译错误、junit测试运行错误、checkstyle代码风格检查错误，以及功能测试、集成测试错误等。当其他人想要提交他们的修改之前，都应改事先查看CruiseControl的结果页面，如果当前CruiseControl没有在运行，并且上一次运行结果为成功，才能提交自己的修改，在提交后，还要保证新的一轮集成成功完成，才算完成了自己的工作。
CruiseControl具备很好的扩展能力，目前已经有很多为CruiseControl编写的插件。eXtreme Feedback Devices (XFDs)（http://www.artima.com/weblogs/viewpost.jsp?thread=67492）就是一个很有意思的插件，该插件的一个功能就可以将CruiseControl的运行结果用一个外接的红绿灯显示出来，如果build成功就亮绿灯，如果失败就亮红灯，以次来让开发人员们对CruiseControl的build结果。
红绿灯图片
另一个trac插件（https://oss.werkbold.de/trac-cc/）可以让CruiseControl将运行结果自动地放到trac上去，使CruiseControl和trac很好地结合了起来。CruiseControl同时还拥有Firefox和Thunderbird（http://www.md.pp.ru/mozilla/cc/）、Eclipse等的插件，使你可以在浏览器的状态栏上及时的看到集成的最新结果。
CruiseControl是用java语言编写的，并且可以运行在各种平台上，然而，并不是只有java程序才能用它来进行持续集成，CruiseControl可以用来做任何语言编写的系统的持续集成，例如C++程序员就可以使用make或jam，配合svn火车cvs来进行持续集成，使用CppUnit、mockpp等工具编写测试。尽管如此，还是诞生了一些在特定平台上运行的持续集成工具，CruiseControl.Net就是其中一个例子。
CruiseControl.Net（http://ccnet.thoughtworks.com）运行在.Net平台上，采用.Net框架实现，在实现了几乎所有的CruiseControl的功能的基础上，提供了对于Windows平台和.Net编程更多更友好的支持。
CruiseControl.Net的一个特点是它集成了对Visual Studio .NET和MSBuild的支持。用户可以将Visual Studio .NET工程的sln文件指定给它，让它运行其中的build、rebuild和clean等功能。在NAnt出现之前，几乎所有开发人员在都是使用Visual Studio .NET来管理他们的.Net项目的。这样，CruiseControl.Net可以支持对原有Visual Studio .NET工程的持续集成，而用户也既可以使用NAnt或者Visual Studio .NET来管理整个项目的构建。MSBuild是Visual Studio 2005项目的标准格式，CruiseControl.Net对其的内建支持可以使大家很容易地将Visual Studio 2005的项目放到CruiseControl.Net中去。
CruiseControl.Net使用Web Dashboard来发布运行结果，它有点类似于CruiseControl中用来发布结果的web应用，不过是用.Net写成的。另外它还包含一个Windows托盘程序CCTray来方便用户随时查看build结果。
DamageControl
在Ruby成为一种新的流行时尚的今天， DamageControl（http://dev.buildpatterns.com/trac/wiki/DamageControl）的出现大概不会让大家感到奇怪，它是一个用ruby写成的持续集成工具，也是由ThoughtWorks公司开发的一个开源产品。DamageControl目前还处于开发阶段，但是已经实现了CruiseControl的绝大部分功能，包括对CVS和SVN的内建支持，同时支持多种自动化构建工具等。
DamageControl区别于CruiseControl的一个显著特性是它提供了一个用Ruby on Rails框架写成的web管理应用程序，用户可以很简单的使用这个web程序来配置持续集成项目。凭借着这个简单的web管理程序，用户可用方便的建立一个持续集成项目，并可以配置运行策略、版本管理、运行结果的查看方式等，而不用像在CruiseControl或CruiseControl.Net里面一样，需要手动修改一个xml配置文件来完成集成项目的配置。
尽管DamageControl目前还处于开发状态，它已经逐渐被广泛应用起来，由于它使用ruby写成的，所以自然会成为ruby项目的首选工具。它的安装也比较简单，用户可以直接从DamageControl项目的SVN代码库中check out出源代码，稍加配置就可以运行了。
DamageControl还实现了一个非常酷的功能: AppCasting。该功能能够让你将你运行完持续集成后得到的系统交付给对你的系统感兴趣的人。当某一次集成运行完毕后，DamageControl会使用一些工具如Ruby Gems, Apt, Maven repository等将你的系统打包，然后在它自己的RSS里面加上一条消息表明新的系统已经被成功构建了。这样，任何订阅了该RSS的人就可以及时的知道某一个项目的进展情况，并且在有新的集成成功运行完成后得到最新被构建的系统以及相关的发布信息。
谈完了这些持续集成工具，我们有必要来看看自动化构建工具，这些工具在持续集成中同样扮演着非常重要的角色，可以这么说，持续集成工具就像一个指挥，而真正完成工作需要依靠这些自动化的构建工具。正是这些工具的存在，是我们可以自动化的完成编译源码、运行测试、打包系统、部署应用等所有这些我们在集成中需要完成的工作。目前在这方面已经有很多非常成熟的开源工具，比如古老的Make，鼎鼎有名的Ant和它在.Net世界中的兄弟NAnt，用ruby写就的Rake等等。在下面的内容中，我将挑选其中的几个工具进行一些介绍。