如何制定有效的配置管理流程

以下是我们在实际工作中遇到的一个例子，这个例子充分说明了正确的工作流程对于保证软件产品质量的重要意义。

 1          问题描述

某一开发团队为其客户开发业务软件，系统上线之后存在着很多的业务需求变更，同时也有很多业务部门在使用过程中所发现的软件缺陷，我们把需求变更和软件缺陷统称为变更。开发团队需要迅速响应客户所提出变更请求，把相应的软件版本修复及时地安装到生产系统上去。

为了保证产品质量，该开发团队建立了以下的软件发布流程：

这四个环节分别对应以下四种环境：

开发环境：开发实现客户的变更请求

测试平台：开发团队把软件发布给客户之前做内部系统测试

准生产环境：客户把软件发布到生产系统之前做验收测试

生产系统：最终的生产系统

当开发团队将变更实现提交用户验收测试时，凡是没有通过验收测试的变更将被拒绝，只有通过验收测试的变更才会被部署到生产系统上去。整个流程如下图所示，假设开发团队总共实现了3个变更，其中变更1和变更2通过了系统测试被提交用户验收测试，但只有变更1通过了用户验收测试，最终只有变更1被部署到生产系统上。

为了支持这种工作流程，该团队分别在配置管理系统中管理了四种源代码版本：

凡是通过每一个环节的变更所对应的源代码版本将被复制到下一个环节的版本基线中去。看上去这一流程非常合理，不是吗？

 

2          质量陷阱

让我们来看这种流程的两个应用案例。

 

场景I：未经测试的版本组合

在下面的例子中，文件f1、f2在修改之前的版本都是1，在实现了变更1、变更2后，它们的版本都变为了版本2，表示为f1(v2)、f2(v2)。在整个的测试过程中，前面三个环境上测试的代码版本始终是文件f1和f2的版本2，但是最后变更1没有通过验收测试而变更2通过了，那么最终被部署到生产系统上去的版本将是：

f1(v1，这是f1原来在生产系统上的版本)

f2(v2，其中已包含了变更2所对应的版本2)

但f1(v1)应该是跟f1(v1，变更1修改以前的版本)相匹配的版本组合，跟f2(v2)相匹配的版本组合应该是f1(v2)，由此可能发生的结果是：

在生产系统上运行的是未经测试的版本组合!

 

场景II：未经测试的版本

在下面的例子中，在前面三个测试环节中，文件f2被测试的版本都是版本4。当变更2未通过用户验收测试时，文件f2最终被复制到生产系统上的版本为3，这个版本是未经测试的。

结果令人难以置信：

在生产系统上运行的是未经测试的版本?!

 

任何一个软件系统，它的所有代码应该被作为一个整体来进行交付，而不是象上述例子中那样只交付部分的代码（变更相关的代码）,这是造成质量陷阱的根本原因。一个看上去合理的流程存在本质的缺陷。

3          改进建议

为了避免以上所述的这些质量陷阱，我们应该改进现有的配置管理流程。

3.1   建立闭环的质量保证流程

选成以上质量隐患的根本原因是系统代码没有被作为一个整体来处理，并且在发布过程中我们发布的是源代码，正确的流程（也是业界较为通行的做法）应该发布构建后的目标码而非源代码。我们可以建立一个闭环的质量保证流程（如下图所示）来批量地进行软件发布。

其中系统测试过程中发现的缺陷应该被开发人员及时改正，然后再做构建，再测试，直到达到一个比较稳定的版本才会发布到验收测试环节。同样的，验收测试中发现的问题也会回到开发环节进行修复。这应该是一个多次循环的过程，不断地发现错误，然后改正，再测试。这个循环到什么时候结束呢？这个取决于各个软件项目的实际情况：

Ø        最理想的情况当然是到所有的缺陷都被改正为止，但是所花的时间比较长，可能赶不上项目的进度要求，现实工作不大可能做到这一点。

Ø        折衷的情况是所有严重的缺陷（即那些影响系统使用的的缺陷）都必须被改正，但允许有一些已发现的缺陷遗留到后面再去解决,前提是所遗留的缺陷不会影响其他变更的实现。大家平时在一些商用软件的新版本中经常可以见到发布说明(Release Notes)中所列的已知缺陷(Known Defects)就是属于这种情况。

我们向开发团队提出这个建议后，马上遭到项目经理的反对：“客户有些紧急的变更需要马上实现并交付生产运营，几乎没有时间来走这样完整的闭环流程。”

3.2   区别对待缺陷和新增功能

通过进一步了解我们发现紧急的变更一般是指影响系统正常使用的软件缺陷，这些缺陷需要及时的修复；而新增功能请求一般不是那么紧急的，允许开发团队有一段时间来开发实现。但开发人员目前是把所有紧急和非紧急的变更请求混杂在一起实现的，往往是一个紧急的缺陷已经修复，但另外一个正在开发中的新增功能也修改了同一组文件版本，造成两者之间的版本依赖，从而导致紧急的缺陷修复不能按时提交。

我们建议把缺陷的修复工作和新增功能的开发工作区分开来，这就涉及到多个版本的并行开发，开发团队主要面临以下三个版本的开发：

Ø        v1.0中的缺陷修复

Ø        v1.0的新增功能版本v1.1

Ø        下一个版本v2.0

这样缺陷修复和新增功能开发相互独立，保证紧急的缺陷修复不会受到新增功能的影响。

3.3   发布版本构建(build)而不是源代码

在这个案例中另外有一个不附合配置管理惯例的地方是在开发、测试、验收、生产四个环节发布的都是源代码，分别需要构建(包括编译)过后才能部署到相应的运行平台上。由于软件构建的结果很可能会受构建平台及相应编译器版本所影响，最终在生产系统上的运行代码(在生产系统上构建得到)与准生产环境上的运行代码(在准生产环境上构建得到)可能不完全一致，有可能造成质量隐患。比较通行的做法是所有平台上运行的构建代码应该只在构建服务器上生成一次，一次编译到处运行，这样才能保证各个平台上所用到的同版本运行代码是同一次构建的产物。构建服务器通常就是由开发平台兼任，但如果是发布多个不同运行平台的版本的话，可以有多个构建服务器存在，如：同一个软件既有 AIX + DB2 平台的运行版本，也有 HPUX + Oracle 平台的运行版本。

除了某些特殊的运行环境外，如IBM主机系统(mainframe)上明确要求在运行平台上对源代码进行编译构建，一般软件系统的开发都可以遵循这一个工作原则。

3.4   版本发布管理

对于所发布的构建版本，我们也需要进行有序的管理，可以用版本号来唯一标识每一个发布版本。一般可以把用于开发团队内部系统测试的称之为内部发布版本，把提交给客户的称之为外部发布版本，这两种软件发布版本都要统一编号管理。在我们的例子中，内部发布版本可以简单地用构建号来表示，如：

v1.0_build_008      表示版本v1.0开发过程中生成的第8次构建外部发布版本可以由版本号和发布号组合而成，如：

v1.0_rel01          表示版本v1.0的第一个外部发布版本

对于v1.0中的缺陷修复，我们可以通过补丁的方式来发布，一个补丁中可以包含有多个缺陷修复，被修复的缺陷需要在补丁的发布说明(Release Notes)中写明，补丁名称可以由版本号、发布号和补丁号组合而成，如：

v1.0_rel01_p001     表示针对发布版本v1.0_rel01的第001号补丁

对于v1.0中新增功能，我们需要制定一个发布计划，根据客户新增功能请求的紧急程度来分期分批实现，一次发布中可以包含多个新增功能，并且包括所有已改正的软件缺陷，这些改动都必须在发布说明中写明，发布版本号可以在前一个发布版本的基础上递增，如：

v1.1_rel02          表示版本v1.1的第二个外部发布版本

对于下一个版本v2.0的开发，则与版本v1.0开发的发布管理完全一致，如：

v2.0_build_002      表示版本v2.0开发过程中生成的第2次构建

 

在版本发布管理的流程中，发布版本的安装应该由专门的角色负责，可以是配置管理员或者是集成员(integrator)；开发人员被禁止向各平台（测试平台、准生产环境、生产系统）上安装任何软件，并且各平台上所安装软件的版本号台试.0.0 Notes 11都应该有详细的记录。当软件缺陷被发现时，我们就可以明确知道问题究竟是出在哪一个版本。

内部发布版本只会被安装到测试平台上，经过 “开发 à 构建 à 测试 à 发现缺陷à 修改代码” 的多次循环之后，内部发布版本的质量趋于稳定，开发团队才会决定做一个外部发布版本。

外部发布版本被安装到准生产环境上，并且只有通过用户验收测试，它才可以被安装到生产系统上去。如果该版本没有通过用户验收测试，那么开发团队需要提供相应的补丁来解决用户验收中发现的问题，直到通过用户验收后再将该发布版本及其所有的累积补丁全部安装到生产系统上去。有些情况下，最终通过验收测试的也可能是下一个发布版本，所以生产系统上安装的发布版本前后之间不一定是连续的，中间可能跳过一些质量不够成熟的版本。

同样的，只有通过用户验收测试的补丁才会被最终安装到生产系统上去。紧急的补丁经过用户验收测试之后会马上安装到生产系统上，不紧急的补丁可以累积几个以后批量安装上去。

 

4          ClearCase 工具实现

配置管理工具 IBM Rational ClearCase 可以很好地支持这种并行开发模式。在 ClearCase UCM (Unified Change Management，统一变更管理流程)工作模式中，我们可以在版本v1.0的发布版本基线(v1.0_rel01)的基础上分别创建针对三种版本(v1.0_bugfix, v1.1, v2.0)的开发项目（如下图所示）。 在 ClearCase 的管理下，这三种版本位于不同的分支上，它们的开发是独立的，互不影响；并且版本 v1.0_bugfix 中的缺陷修复可以及时地合并到版本 v1.1 和 v2.0 中去，版本 v1.1 中的新增功能也可以在需要的时候合并到版本 v2.0 中去。

ClearCase 也为开发人员提供了方便易用的工作界面 ClearCase Explorer,开发人员可以方便地选择任何一个版本项目来进行开发工作，ClearCase Explorer 可以迅速准确地准备相应的工作版本。所以这三种不同版本的开发完全可以由同一组开发人员来完成，大大提高了开发的工作效率。

 

 

5          总结

在这个案例学习中我们看到配置管理流程对于保证软件质量起着非常重要的作用，不恰当的流程可能导致潜在的质量缺陷，开发团队需要根据自身项目的情况来制定一个高效合理的配置管理流程。有了一个好的流程，还需要一个好的配置管理工具来简化我们的管理工作，从而保证开发人员的工作效率和软件质量。