随着软件业的不断发展，软件项目的规模越来越大，软件结构越来越复杂，技术要求越来越高，参与人员越来越多，管理也变得越来越难。在这样一个大背景下，如何提高软件研发质量，相信是所有软件公司都在关注的话题。但是，如何提供研发质量，这决不仅仅是一个口号，我们必须有一套行之有效的方法加以管理。然而有效的管理带来的负面影响往往是成本的提高，这包括时间的成本、人力的成本、资金的成本。在大多数软件研发项目中，时间总是很紧，人力和资金也是有限的。这样，管理者往往步入一种两难的境地：一方面为了提高研发质量而需要加大对时间、人力、资金的投入，另一方面现实情况却不允许我们这样做，这也是很多管理制度不能真正实施下去的原因。难倒没有第三种方案能兼顾二者吗？时下正流行的持续集成技术为我们提供了一个答案。
持续集成（Continuous Integration，简称CI），又被称为持续构建（Continuous Build），最初是以一种研发管理的思想被提出来。1996年，持续集成的思想首先在Kent Beck的极限编程中被提了出来。Kent Beck在他的书中是这样描述的：“团队编程就是先分而治之地解决问题，然后集成。但集成的过程是不可预知的，你等待集成的时间越长，付出的代价就可能越高。因此，每完成一段时间编程，系统就应当进行一次集成，并进行相应的测试。”Kent Beck先生将这里的“一段时间”设定在几个小时，并提出了集成的同时应当进行测试的思想（这就是敏捷开发中的测试驱动设计）。
后来，持续集成的思想被敏捷开发所吸收，并进一步提出了增量开发的思想。过去，我们解决复杂软件系统问题的编程思想是分而治之。所谓分而治之，就是将大系统划分成若干小模块，再划分为一个个小问题，分别予以解决，最后再集成。运用这样的思想，集成的周期必然很长，可能是数周甚至数月，其风险不言而喻。
增量开发改变了这样的思想。虽然它依然是将大系统划分为无数的小模块、小问题，但它不是一股脑地立即去解决所有问题，而是有选择性地解决最核心、最主要的问题，然后再以进化的方式增量开发、逐渐完善，进而解决其它问题。在这样一个过程中，每进化一次就集成一次，产生一个可运行的成果，以此循环往复，直到最终完成。这样一个过程就是迭代式软件开发的过程。
然而，采用持续集成的方式固然好，但每几个小时就要集成一次、测试一次，如果人为地去完成，成本依然是巨大的。因而，在敏捷开发大师Martin Fowler的推动下，持续集成工具诞生了。
持续集成工具，就是将程序员提交的代码，定期从配置管理库（如svn、vss）中下载下来，集成、编译、测试，最后发布到应用服务器（如weblogic）中，同时打包形成一个版本的发布产品。一个持续集成工具，需要一个配置管理库，一个构建工具（如Ant、Maven）。同时，它还可以集成一些静态代码检查工具（如CodeStyle、PMD、FindBugs），进行自动化的代码规范性检查，以提高代码编写质量。最后，它还需求我们提供JUnit测试用例程序，进行自动化测试，虽然这并不是必选项目。
持续集成工具将不可靠的人为操作，转变成了机械自动化操作，使不提高项目成本的前提下提高了研发质量成为了可能。
