对于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 总结

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