持续集成（一）思想篇

 定义

      持续集成（ContinuousIntegration，简称CI），又被称为持续构建（ContinuousBuild），最初是以一种研发管理的思想被提出来。1996年，持续集成的思想首先在Kent Beck的极限编程中被提了出来。KentBeck在他的书中是这样描写叙述的：“团队编程就是先分而治之地解决这个问题，然后集成。但集成的过程是不可预知的，你等待集成的时间越长，付出的代价就可能越高。因此，每完毕一段时间编程，系统就应当进行一次集成，并进行对应的測试。”KentBeck将这里的“一段时间”设定在几个小时，并提出了集成的同一时候应当进行測试的思想，这也就是敏捷开发中的測试驱动设计。

 

     我们再来听听敏捷大师MartinFowler对持续集成的定义：持续集成是一种软件开发实践，即团队开发成员常常集成它们的工作，通常每一个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自己主动化的构建（包含编译，公布，自己主动化測试)来验证，从而尽快地发现集成错误。很多团队发现这个过程可以大大降低集成的问题，让团队可以更快的开发内聚的软件。

 

        简言之，持续集成就是开发者把代码多次提交，自己主动化集成构建，公布的过程。多次，多到什么程度呢？多到，一天，甚至几小时提交，集成，构建一次。这样能够早早的发现集成中出现的错误，不会把错误积压到最后，导致，找错，排错非常困难，并且这些过程都是机器自己主动化进行的，大大提高了开发效率，和开发质量。当然了，关于持续集成的长处多多，暂且在这里不论。

 

产生背景

 

    随着软件业的发展，软件项目的规模越来越大，软件结构越来越复杂，技术要求越来越高，參与人员越来越多，管理也变得越来越难。在这样一个大背景下，怎样提高软件开发效率和质量，减少软件开发成本，成为软件行业的主题。然而在开发中能有一套行之有效的方法加以管理，这是最迫切的需求。可是有效的管理带来的负面影响往往是成本的提高，这包含时间的成本、人力的成本、资金的成本。在大多数软件开发项目中，时间总是非常紧，人力和资金也是有限的。这样，管理者往往步入一种两难的境界：一方面为了提高软件质量而须要加大对时间、人力、资金的投入，还有一方面现实情况却不同意我们这样做，这也是非常多管理制度不能真正实施下去的原因。就在这种背景下，持续集成就应运而生了。它在软件开发过程中为开发者攻克了非常多难题。

 

    后来，持续集成的思想又被敏捷开发所吸收，并进一步提出了增量开发的思想。过去，我们解决复杂软件系统问题的编程思想是分而治之。所谓分而治之，就是将大系统划分成若干小模块，再划分为一个个小问题，分别予以解决，最后再集成。运用这种思想，集成的周期必定非常长，可能是数周甚至数月，其风险不言而喻。

 

    增量开发改变了这种思想。尽管它依旧是将大系统划分为无数的小模块、小问题，但它不是一股脑地马上去解决全部问题，而是有选择性地解决最核心、最基本的问题，然后再以进化的方式增量开发、逐渐完好，进而解决其他问题。在这样一个过程中，每进化一次就集成一次，产生一个可执行的成果，以此循环往复，直到终于完毕。

 

    然而，採用持续集成的方式固然好，但每几个小时就要集成一次、測试一次，假设人为地去完毕，成本依旧是巨大的。因而，在敏捷开发大师MartinFowler的推动下，持续集成工具诞生了。

 

工具介绍

    持续集成工具，就是将程序猿提交的代码，定期从配置管理库（如svn、vss）中下载下来，集成、编译、測试，最后公布到应用server（如weblogic）中，同一时候打包形成一个版本号的公布产品。一个持续集成工具，须要一个配置管理库，一个构建工具（如Ant、Maven）。同一时候，它还能够集成一些静态代码检查工具（如CodeStyle、PMD、FindBugs），进行自己主动化的代码规范性检查，以提高代码编写质量。最后，它还需求我们提供JUnit測试用例程序，进行自己主动化測试，尽管这并非必选项目。

 

    持续集成工具将不可靠的人为操作，转变成了机器自己主动化操作，在不提高项目成本的前提下大大的提高了软件开发效率和质量成为了可能。

 

总结

    持续集成，事实上是一种思想，是软件开发管理自己主动化，智能化的一种思想，更是软件业发展的趋势。而我们须要做的就是在开发过程中来实现这样的思想，利用各种软件工具来构建一个更自己主动化，智能化的软件生产工厂来实现它。当然了，在这个智能化的软件生产工厂中，持续集成仅仅是非常小的一部分实现而已，我们要做的还有很多其它。

 

    接下来，关于持续集成的工具介绍及怎样搭建持续集成开发环境，请关注兴许博客。