基于IBM Rational Build Forge实现敏捷开发过程中的持续构建

基于IBM Rational Build Forge实现敏捷开发过程中的持续构建2009-12-11 IBM.COM 曾文丽在敏捷开发过程中，软件构建周期以及自动化程度直接影响开发的速度和质量。本文结合具体的软件开发项目，描述如何利用 IBM Rational Build Forge 在敏捷开发过程中实现完全自动化的软件构建，产品安装以及单元测试，进行每天持续快速构建，提高开发团队的效率，改进产品和开发质量。

概述

敏捷开发（Agile development）是一种以人为核心、迭代、循序渐进的开发方法，开发周期一般是两星期到四星期。敏捷开发的一大原则是尽早的、持续的交付有价值的软件来使客户满意，交付的间隔时间越短越好。如何才能在很短的时间内实现产品的交付呢？每天持续构建能为实现短时间交付软件提供很好的质量保证。

由于开发过程中每天都会有大量的代码在修改，这些改动可能会给产品带来潜在的问题。因此，为了尽早发现开发中存在的问题，代码需要不断地集成，并频繁地进行构建（Build）、测试以及提交。如果构建不能够完全自动化，频繁的构建就需要花费大量的人力和时间。但是实现构建自动化的过程也是一项繁琐，复杂的工作。IBM Rational Build Forge 提供了很好的持续构建框架，可以实现端到端流程的自动化。它不仅可以使用自有的脚本，还可以集成用户现有的脚本和工具，因此可以有效利用现有的资源，同时它具有任务定制功能，可以周期性启动所需的构建工程，提供一个可重复的、可靠的应用开发生命周期流程。

持续集成过程

2.1 典型的持续集成过程

持续集成过程中一般存在两种构建：本地构建和集成构建。本地构建一般是开发人员完成代码修改后，在自己的本机完成；集成构建一般是集成了所有开发人员的代码，由专业的构建工程师完成。典型的持续集成过程如图 1 所示，开发人员获得开发代码，开发人员进行开发工作后，各自进行本地构建。经过一定的开发时间，合并团队开发成果，再次进行本地构建，如果该本地构建成功，开发人员就可以提交代码到集成分支，构建工程师进行集成构建并进行发布。

图 1. 典型的持续构建流程

项目 R 根据典型的持续构建过程，结合敏捷开发方式，对此典型的持续集成过程进行适当的修改。

2.2 项目 R 的持续集成过程

项目 R 的敏捷开发采用 Scrum 开发方式，一个版本的开发分为若干个 Sprint，一个 Sprint 一般为期四周。在每个 Sprint 中，需要三至四个集成构建，期间每天需要三个本地构建。根据项目提出的构建需求，项目 R 的构建采用了本地构建与集成构建相结合的持续构建方式，使用 Build Forge 的任务定制功能实现每天三个本地构建。

为了适应敏捷开发以及持续构建的需求，我们对项目的开发模式、代码配置管理和构建流程进行相应的修改。项目R使用的代码配置管理工具是 ClearCase（以下简称 CC）。在进行敏捷开发之前，每个开发人员都有单独的开发流（Stream），每次做集成构建之前，各开发人员需要把代码提交到集成流里，然后创建基线（Baseline），构建工程师从最新的基线里面检出代码，进行集成构建。如果开发人员之间的程序具有相互依赖关系，但又没有及时沟通，往往会导致集成构建的失败。采用敏捷开发以后，为了开发人员更方便获取其它开发人员的代码，建立了一个统一的开发流，所有的开发人员都基于该流进行开发，每天在该流上进行 3 个本地构建以尽快发现各种问题。通过本地构建，确认代码正确以后，才提交代码到集成流，创建基线，进行集成构建。采用敏捷开发方式以后的 CC 策略如图 2 所示。

图 2. ClearCase 简化的开发分支策略示意图

CC 的开发策略修改以后，项目R采用的持续构建过程如图 3 所示。开发人员在开发流上进行开发活动，本地构建根据定制任务的时间周期性地启动。如果本地构建成功，并且需要进行集成构建时，开发人员提交代码并创建基线进行集成构建。

图 3. 项目 R 持续集成过程