【IT168 技术文章】

    在本文中，我们将通过以下内容，说明在实际项目中如何使用ClearCase，来达到我们的配置管理需要。

    统一标识工件，并存入安全的配置库

    控制和审计工件的变更

    在项目的里程碑处建立相应的基线

    支持对工件的并发变更

    设置测试环境

    历史数据迁移

    1 统一标识工件，并存入安全的配置库

    1.1 配置库的创建

    为了将标识出的工件存入安全的配置库，我们首先需要创建配置库。

    在创建配置库前，我们需要根据不同的管理需要，设置不同的库，例如：编辑库、测试库、产品库等。有的公司则划分为产品发布库、产品受控库、产品研发库。不管采用哪种划分方式，实际都是类似的，都是依据项目开发管理需要来进行划分的。假设我们分为编辑库、测试库、产品库，那么这些库分别对应着项目成员工作区、测试人员获取测试程序的工作区、产品正式发布版本的存放位置。

    在传统手工配置管理方式下，这些不同的配置库之间很多都是通过文件拷贝方式实现各个库的管理。这种方式存在两个问题：一是由于这些配置库之间不是孤立的库，而是相互联系的，它们之间不能通过简单的文件拷贝方式复制；二是，每个配置项在项目的配置库中应该只有一份，这种采用文件拷贝的方式违背了配置管理系统中配置项的唯一性要求。在ClearCase中，我们可以使用分支或者流的方式进行映射。

    针对不同的配置库，我们需要有不同的安全设置或权限控制。例如，测试库和产品库，只能由配置管理员进行成果的提交；而编辑库作为项目成员的工作区，则不进行权限控制。但是假设项目由多个开发商负责开发，那么对于编辑库，我们则需要针对不同开发商就开发模块/子系统进行相应的权限控制。

    进行配置管理时，我们需要对那些将处于版本控制下的工件进行统一标识。就配置管理工具而言，标识意味着能够快速方便地查找和确定项目或系统的工件。如果你曾参与或管理过一个没有配置管理，或配置管理做的很差的项目，你会发现标识正确的文件的正确的版本是多么的困难，因为到处都有拷贝。最坏的情况，丢失或错误标识工件的版本会导致项目的失败，那么由于丢失的部分延迟了系统的提交，要么因为错误的部分降低了系统的品质。

    配置项的标识既包括用户管理和设计系统的工件（例如项目计划、设计模型等），也包括用于实现系统设计的工件（如源代码、库、可执行文件等）。这两种类型的配置项都很容易标识，也不容易遗漏。这里我们要强调的是在实际项目中配置项标识中，很容易忽视和遗漏的一类配置项。这类配置项就是项目的一些支撑信息，例如基础数据、配置参数、建表文件，操作系统基础参数等。很多项目不认为这类信息也应该作为配置项纳入配置库进行配置管理。试想，假设生产系统异常崩溃，那么项目组拿什么数据去恢复生产环境，因为仅有源码是不够的。所以，生产系统运行支撑的所有信息，都应该作为配置项纳入配置库进行配置管理。

    除了统一标识、完整标识所有的配置项外，对于不同类型的配置项，我们还需要明确不同的文件保存方式。对于设计系统的工件（如项目计划等）、实现系统设计的工件（如源码等），这些配置项都有特定的文件格式，所以在配置库中的保存没有什么特别。但是对于建表文件、配置参数等支撑信息，则需要明确文件保存方式。例如，系统公共配置参数，这些是存放在数据库中的，如何对这些文件进行管理和控制，如何在配置库中保存这些文件，这是需要配置管理员和项目关系人经过分析和讨论后明确下来的。例如，在某项目中，根据项目实际情况，笔者针对各种类型的配置项，定义了相应的文件保存方式（见图一）。

    组织工件并能够定位这些工件还是不够的。针对那些关键资产，其配置库还应该具备可容错和可复制能力。对于所有的软件资产，配置库是潜在的故障集中点，因此配置库必须是可容错和可复制的。

    除此之外，我们还应该有适当的过程对配置库做备份和灾难恢复。如果没有完备的备份过程，即使我们将所有的配置项都纳入配置库了，但是一旦发生配置管理系统崩溃的情况，我们一样将丢失公司的软件资产，所以，定义适当的备份过程，是保证工件存入安全配置库的一个很重要的环节。