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

hunterccc

, V" q; O  H, h( w  {/ d% F持续集成 研发管理 极限编程 敏捷开发 迭代开发
    随着软件业的不断发展，软件项目的规模越来越大，软件结构越来越复杂，技术要求越来越高，参与人员越来越多，管理也变得越来越难。在这样一个大背景下，如何提高软件研发质量，相信是所有软件公司都在关注的话题。但是，如何提供研发质量，这决不仅仅是一个口号，我们必须有一套行之有效的方法加以管理。然而有效的管理带来的负面影响往往是成本的提高，这包括时间的成本、人力的成本、资金的成本。在大多数软件研发项目中，时间总是很紧，人力和资金也是有限的。这样，管理者往往步入一种两难的境地：一方面为了提高研发质量而需要加大对时间、人力、资金的投入，另一方面现实情况却不允许我们这样做，这也是很多管理制度不能真正实施下去的原因。难倒没有第三种方案能兼顾二者吗？时下正流行的持续集成技术为我们提供了一个答案。
( r- H8 x" n; C3 B! R+ z7 O
3 z! W- p7 P9 @0 ^$ w4 B' ?' C持续集成（Continuous Integration，简称CI），又被称为持续构建（Continuous Build），最初是以一种研发管理的思想被提出来。1996年，持续集成的思想首先在Kent Beck的极限编程中被提了出来。Kent Beck在他的书中是这样描述的：“团队编程就是先分而治之地解决问题，然后集成。但集成的过程是不可预知的，你等待集成的时间越长，付出的代价就可能越高。因此，每完成一段时间编程，系统就应当进行一次集成，并进行相应的测试。”Kent Beck先生将这里的“一段时间”设定在几个小时，并提出了集成的同时应当进行测试的思想（这就是敏捷开发中的测试驱动设计）。
: e0 S6 H9 V" M9 }( P! X, n0 Y
后来，持续集成的思想被敏捷开发所吸收，并进一步提出了增量开发的思想。过去，我们解决复杂软件系统问题的编程思想是分而治之。所谓分而治之，就是将大系统划分成若干小模块，再划分为一个个小问题，分别予以解决，最后再集成。运用这样的思想，集成的周期必然很长，可能是数周甚至数月，其风险不言而喻。
2 f0 F2 K& c* M, |) V
0 _# B6 V0 O* N, I, \  j/ v增量开发改变了这样的思想。虽然它依然是将大系统划分为无数的小模块、小问题，但它不是一股脑地立即去解决所有问题，而是有选择性地解决最核心、最主要的问题，然后再以进化的方式增量开发、逐渐完善，进而解决其它问题。在这样一个过程中，每进化一次就集成一次，产生一个可运行的成果，以此循环往复，直到最终完成。这样一个过程就是迭代式软件开发的过程（详见 《一次迭代式开发的研究：怎样进行迭代式开发》）。
; R% q! K" D% g+ a# Y0 I
3 f( E1 `# R+ I6 B' l. P然而，采用持续集成的方式固然好，但每几个小时就要集成一次、测试一次，如果人为地去完成，成本依然是巨大的。因而，在敏捷开发大师Martin Fowler的推动下，持续集成工具诞生了。
5 H: r" x% }% d/ h0 l9 X3 i7 _
持续集成工具，就是将程序员提交的代码，定期从配置管理库（如svn、vss）中下载下来，集成、编译、测试，最后发布到应用服务器（如weblogic）中，同时打包形成一个版本的发布产品。一个持续集成工具，需要一个配置管理库，一个构建工具（如Ant、Maven）。同时，它还可以集成一些静态代码检查工具（如CodeStyle、PMD、FindBugs），进行自动化的代码规范性检查，以提高代码编写质量。最后，它还需求我们提供JUnit测试用例程序，进行自动化测试，虽然这并不是必选项目。
/ l- j7 K4 G4 f- X# C9 ~0 h
持续集成工具将不可靠的人为操作，转变成了机械自动化操作，使不提高项目成本的前提下提高了研发质量成为了可能。

" B' a* `" h; N& K, `

faker12

持续集成的思想被敏捷开发所吸收，并进一步提出了增量开发的思想

CLBuu

有效的管理带来的负面影响往往是成本的提高

xiananUZI

采用持续集成的方式固然好，但每几个小时就要集成一次、测试一次，如果人为地去完成，成本依然是巨大的