既然认为它是好的，就要发挥到极限，这是XP的思想。
持续集成无疑是一种非常好的方法，那么在实际的软件开发过程中就应该把它的好发挥到极限，但就我自己经历过的项目以来，只在一个项目中真正的较好的实现了持续集成，不知道大家的情况是怎么样？持续集成的最出名的代表还是MS的Daily Build和冒烟测试了。
持续集成的好处1、集成变得自动化，不依赖人工。
这点好处对于项目是多工程的情况下特别的明显，可以想想，一个项目在多工程的情况下，如果不是 自动集成部署，而需要人手工的话，需要耗费多大的精力，对于单工程的项目来说这点可能不是那么的明显。
2、尽早的发现集成出现的错误。
在不做持续集成的情况下，项目通常也许是在一个迭代的后期才开始将所有人做的东西进行集成，这个时候才暴露出集成的问题，这个时候再去查就已经非常困难了，因为东西已经很多了，采用持续集成可一定程度减少这个问题，因为持续集成保证了每次都只是小部分的集成，出现问题的话也知道范围被锁定在一个小的部分，而且通常可通过单元测试、功能测试以及集成测试来保证在持续集成进行时尽早发现错误，提醒导致持续集成失败的相关人员。
3、不断的发布新的可运行版本。
这点无论是对于开发人员、项目管理人员和客户带来的好处都是很明显的，对于开发人员来说每天可以通过这个版本看到自己所完成的任务，增强任务完成的满足感；对于项目管理人员来说则可以看到项目的开发在按计划的进行；对于客户来说，可以尽早的看到系统以确定和需求的符合性。
持续集成的实现
既然持续集成这么好，那就在项目中引入持续集成吧，怎么样让项目变得可进行持续集成呢？在开源界中对于持续集成有非常多的良好的支持工具，对于持续集成而言，通常是两个部分：
项目自动部署项目自动部署的工具可选择采用ant或maven，通过将之前项目手动部署的步骤翻译为ant或maven的编译脚本来完成项目的自动部署，当然，这要求对于ant或maven一定程度的熟悉，不过无论是ant还是maven都很容易上手，同时可能会需要对原有工程进行一定的改造，如采用maven一般都需要先把引用的包全部归入一个 仓库中。
一个项目的自动部署脚本有些时候可能很简单，有些时候会很复杂，所有有些自动部署脚本真的是可能需要写上个一天，但这是非常值得的。
在自动部署脚本编写完毕后，就可以通过命令或在IDE中直接部署就可完成整个项目的自动部署的动作。
通常项目自动部署的过程需要有这么几步：
1、清空以往的编译。
2、编译项目工程。
3、运行项目工程中的单元测试。
4、部署工程。
5、如为多工程的项目则其他工程也需要重复上面的1、2、3、4步骤。
6、运行功能测试。
7、生成项目网站(以便查看项目的代码情况、测试运行情况等)(可选)。
在自动部署完成时，即可看到项目的运行版本，同时从项目网站中可了解项目的代码情况、测试的运行情况等。
项目持续集成项目持续集成的工具可选择采用luntbuild或cruisecontrol(简称cc)，两者各有千秋，这里不进行比较。项目持续集成需要根据项目所需要的持续集成的情况来编写相应的持续集成脚本(luntbuild可通过web管理界面完成，cc通过编写脚本完成)，通常项目持续集成的脚本会涉及到这些：
1、决定是采用版本管理工具(cvs)感知的方式或每日定时(nightly-build、daily-build)进行持续集成的方式，如决定采用版本管理工具感知的方式，需要确定对于版本管理工具状态获取的频率，如每隔20分钟检查一下是否有更新。
2、持续集成进行，首先是从版本管理工具中获取最新的系统版本，接着就是调用项目自动部署脚本完成项目的自动部署(luntbuild和cc都可直接的调用ant或maven脚本)。
3、合并自动部署后的测试结果到日志中(这点在cc中是要做的，对luntbuild不清楚)。
4、根据自动部署的结果通知相关的人员(email、jabber等等都可以)。
在脚本编写完成后，启动工具项目即可进行持续集成了，可以通过持续集成的网站去查看项目的持续集成情况，其中会包含持续集成执行过程的信息、测试执行的情况、持续集成的统计分析等。
总的来说搭建项目的持续集成环境不会太困难，只要对ant或maven、luntbuild或cc有一定的熟悉，同时明白项目手动部署是如何进行的。
关于工具的使用可以参见几个工具的网站，同时也可
满江红.开源参考上的《持续集成实践之cruisecontrol》。
经验总结
从03年开始在自己所经历的项目中就开始实行持续集成，但最终执行的好的只有一个项目，到底是什么原因呢？在这些项目中项目的持续集成环境都是搭建好了的，但就是没执行好，总结下来发现的问题就在于：
1、开发人员没有对持续集成形成足够的重视。
在几个项目中都是因为持续集成在失败后就没人去调好，因为在开发人员本机运行是好的，放入CVS后由于持续集成进行时的环境不一样确实是有可能会造成失败的，但持续集成失败后无人重视，导致之后的持续集成一直就没什么意义。
2、缺乏足够的测试。
导致了项目即使持续集成成功了但可运行版本中仍然是有N多的bug，这说明持续集成是非常需要单元测试、功能测试的支撑的，否则意义将大打折扣。
还有一个是持续集成通常需要耗费很长的时间，web型系统的持续集成通常需要重启web应用服务器；第一个问题倒是可以通过采取增量方式进行持续集成来解决，但由于不是工具直接支持的，所以这块实现还是比较麻烦的；第二个问题就比较麻烦了，反正在我自己经历的项目中这个问题一直没很好的解决，通常是需要在持续集成结束后人工手动的启动web应用服务器(我试着在cc脚本的最后去启动应用服务器，仍然是无效的)。
无论如何，持续集成带来的好处是非常明显的，值得去做，既然是好的，就要把它发挥到极限(对持续集成给予足够的重视、增加测试)，那就让我们在项目中实现持续集成吧！