如何提高研发质量与持续集成

随着软件业的不断发展，软件项目的规模越来越大，软件结构越来越复杂，技术要求越来越高，参与人员越来越多，管理也变得越来越难。在这样一个大背景下，如何提高软件研发质量，相信是所有软件公司都在关注的话题。但是，如何提供研发质量，这决不仅仅是一个口号，我们必须有一套行之有效的方法加以管理。然而有效的管理带来的负面影响往往是成本的提高，这包括时间的成本、人力的成本、资金的成本。在大多数软件研发项目中，时间总是很紧，人力和资金也是有限的。这样，管理者往往步入一种两难的境地：一方面为了提高研发质量而需要加大对时间、人力、资金的投入，另一方面现实情况却不允许我们这样做，这也是很多管理制度不能真正实施下去的原因。难倒没有第三种方案能兼顾二者吗？时下正流行的持续集成技术为我们提供了一个答案。 

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

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

增量开发改变了这样的思想。虽然它依然是将大系统划分为无数的小模块、小问题，但它不是一股脑地立即去解决所有问题，而是有选择性地解决最核心、最主要的问题，然后再以进化的方式增量开发、逐渐完善，进而解决其它问题。在这样一个过程中，每进化一次就集成一次，产生一个可运行的成果，以此循环往复，直到最终完成。这样一个过程就是迭代式软件开发的过程（详见《一次迭代式开发的研究：怎样进行迭代式开发》）。 

然而，采用持续集成的方式固然好，但每几个小时就要集成一次、测试一次，如果人为地去完成，成本依然是巨大的。因而，在敏捷开发大师Martin Fowler的推动下，持续集成工具诞生了。 

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

持续集成工具将不可靠的人为操作，转变成了机械自动化操作，使不提高项目成本的前提下提高了研发质量成为了可能。 

-------------------------------------------------------------------------------------------------------------------------------

持续集成工具简介

2001年2月，在软件开发各领域有所建树的17位大师联合发表了《敏捷软件开发宣言》，提出了敏捷开发这一概念，至此敏捷软件开发风靡世界，为无数软件开发项目所采用。而在所有这些运用敏捷开发获得成功的软件项目中，运用持续集成工具无疑成为一项最重要的最佳实践，因为它集中体现了敏捷开发的各项思想。 

持续集成工具的意义  

首先，它促进了项目团队的 沟通 与 反馈 。想想看，持续集成工具使每个人每天的劳动成功及时发布到应用服务器上。你只要登陆服务器，就可以运行和查看整个项目的每项功能。开发人员可以相互学习各自的设计，需求人员可以确认开发成功是否符合需求，测试人员可以及时测试各项功能。再这样一个平台下，沟通变得简便，反馈也因而变得及时。如果需要，项目组可以随时拿出最新开发成果向客户展示，以便获得他们的反馈。 

其次，它促使项目开发过程中的许多工作变得 简单 。每天都要无数次地下载最新代码、集成、编译、发布，还要检查代码是否规范，测试各项功能是否正常运行，这是多么巨大而繁琐的工作啊！因为持续集成工具的存在，你只需要及时上传代码，时不时看看反馈结果，多么easy的事情。它使我们腾出了大量时间去做更重要的事情——程序应当怎样设计，这无疑提高了团队工作效率。 

另外，它使得 增量 与 迭代 的开发模式成为了可能。需求人员可以尽早地看到开发成果，以便尽早地与客户确认需求，纠正需求方面的问题；测试人员可以与开发过程并行，使测试工作更加充分，时间更加充足；项目经理则可以更加实时地掌握项目进度，保证项目顺利完成。 

最后，它为开发团队提供了机会和 勇气 去及时纠正他们的错误。这一点可能不太能让人理解，但却是极度重要的。再有经验的需求分析师也有理解不到位的分析，再有经验的开发工程师也有设计不到位的程序代码。每天集成的工作，为我们及时发现问题提供了条件（问题发现得越晚，付出的代价就越大）。发现问题以后怎么办呢？也许就需要及时的摒弃有问题的代码，及时进行重构。但在过去，我们常常没有这样的勇气去重构，因为害怕它影响其它的程序。这是一个谁多说不清的潜在威胁。而现在，有了持续集成和自动化测试过程，我们可以勇敢地重构代码、彻底地解决问题。 

主流的持续集成工具  

目前，比较主流的持续集成工具很多，最著名的当数CruiseControl，而当下的新锐则是Hudson。CruiseControl（ http://cruisecontrol.sourceforge.net/ ）是敏捷大师Martin Flowler旗下的产品，又是免费和开源产品。凭借大师与开源产品的号召力，当仁不让成为持续集成领域的巨无霸。它提供了与几乎所有主流配置管理工具的集成，包括CVS、SVN、VSS、CM Synergy等等，（CruiseControl没有提供对SourceAnyWhere for VSS的支持，但SAWV 5.4以上提供了对CruiseControl.Net的支持）。同时，它提供了对最主流的Ant与Maven构建工具的集成，提供了对.Net和Ruby的支持，功能不可谓不强大。 

虽然CruiseControl功能强大，但随着后起之秀的一个个出现，它的劣势被凸显出来，如安装配置过于复杂、功能扩展能力不足等。在众多后起之秀中，Hudson无疑是最耀眼的一个。Hudson（ http://java.net/projects/hudson/ ）最吸引人的特性是它很容易配置：很难找到如此容易设置的 CI 服务器，也很难找到开箱即用特性如此丰富的CI 服务器。而Hudson 容易使用的另一个原因是它具有强大的插件框架 ，所以很容易添加特性。例如，一个 Hudson 插件可以随时间的推移不断跟踪FindBugs 和代码覆盖。但Hudson只能运行在JDK1.5以上版本，这对于一些老项目来说只能是望洋兴叹。 

http://fangang.iteye.com/blog/1330819

http://fangang.iteye.com/blog/1333304