持续集成（ContinuousIntegration，简称CI），又被称为持续构建（ContinuousBuild），最初是以一种研发管理的思想被提出来。1996年，持续集成的思想首先在Kent Beck的极限编程中被提了出来。KentBeck在他的书中是这样描述的：“团队编程就是先分而治之地解决问题，然后集成。但集成的过程是不可预知的，你等待集成的时间越长，付出的代价就可能越高。因此，每完成一段时间编程，系统就应当进行一次集成，并进行相应的测试。”KentBeck将这里的“一段时间”设定在几个小时，并提出了集成的同时应当进行测试的思想，这也就是敏捷开发中的测试驱动设计。
我们再来听听敏捷大师MartinFowler对持续集成的定义：持续集成是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。
简言之，持续集成就是开发人员把代码多次提交，自动化集成构建，发布的过程。多次，多到什么程度呢？多到，一天，甚至几小时提交，集成，构建一次。这样可以早早的发现集成中出现的错误，不会把错误积压到最后，导致，找错，排错很困难，而且这些过程都是机器自动化进行的，大大提高了开发效率，和开发质量。当然了，关于持续集成的优点多多，暂且在这里不论。
随着软件业的发展，软件项目的规模越来越大，软件结构越来越复杂，技术要求越来越高，参与人员越来越多，管理也变得越来越难。在这样一个大背景下，如何提高软件开发效率和质量，降低软件开发成本，成为软件行业的主题。然而在开发中能有一套行之有效的方法加以管理，这是最迫切的需求。但是有效的管理带来的负面影响往往是成本的提高，这包括时间的成本、人力的成本、资金的成本。在大多数软件开发项目中，时间总是很紧，人力和资金也是有限的。这样，管理者往往步入一种两难的境地：一方面为了提高软件质量而需要加大对时间、人力、资金的投入，另一方面现实情况却不允许我们这样做，这也是很多管理制度不能真正实施下去的原因。就在这样的背景下，持续集成就应运而生了。它在软件开发过程中为开发人员解决了很多难题。
后来，持续集成的思想又被敏捷开发所吸收，并进一步提出了增量开发的思想。过去，我们解决复杂软件系统问题的编程思想是分而治之。所谓分而治之，就是将大系统划分成若干小模块，再划分为一个个小问题，分别予以解决，最后再集成。运用这样的思想，集成的周期必然很长，可能是数周甚至数月，其风险不言而喻。
增量开发改变了这样的思想。虽然它依然是将大系统划分为无数的小模块、小问题，但它不是一股脑地立即去解决所有问题，而是有选择性地解决最核心、最主要的问题，然后再以进化的方式增量开发、逐渐完善，进而解决其它问题。在这样一个过程中，每进化一次就集成一次，产生一个可运行的成果，以此循环往复，直到最终完成。
然而，采用持续集成的方式固然好，但每几个小时就要集成一次、测试一次，如果人为地去完成，成本依然是巨大的。因而，在敏捷开发大师MartinFowler的推动下，持续集成工具诞生了。
持续集成工具，就是将程序员提交的代码，定期从配置管理库（如svn、vss）中下载下来，集成、编译、测试，最后发布到应用服务器（如weblogic）中，同时打包形成一个版本的发布产品。一个持续集成工具，需要一个配置管理库，一个构建工具（如Ant、Maven）。同时，它还可以集成一些静态代码检查工具（如CodeStyle、PMD、FindBugs），进行自动化的代码规范性检查，以提高代码编写质量。最后，它还需求我们提供JUnit测试用例程序，进行自动化测试，虽然这并不是必选项目。
持续集成工具将不可靠的人为操作，转变成了机器自动化操作，在不提高项目成本的前提下大大的提高了软件开发效率和质量成为了可能。
持续集成，其实是一种思想，是软件开发管理自动化，智能化的一种思想，更是软件业发展的趋势。而我们需要做的就是在开发过程中来实现这种思想，利用各种软件工具来构建一个更自动化，智能化的软件生产工厂来实现它。当然了，在这个智能化的软件生产工厂中，持续集成只是很小的一部分实现而已，我们要做的还有更多。
接下来，关于持续集成的工具介绍及如何搭建持续集成开发环境，请关注后续博客。
原文地址：http://blog.csdn.net/gelupu/article/details/38071521
