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

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的第一个外部发布版本