摘要：本文根据配置管理员在实际项目中使用ClearCase时碰到的或是关注的问题，结合配置管理最佳实践，交流笔者在实际项目中使用的应用经验。

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

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

        控制和审计工件的变更

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

        支持对工件的并发变更

        设置测试环境

        历史数据迁移

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

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

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

图一不同类型配置项存放方式

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

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

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

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

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

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

1.2    配置库的备份
        完成配置库的创建后，我们就需要定义适当的配置库备份过程。配置管理系统的备份包括VOB、视图、注册信息等，这里我们主要说明如何对VOB进行备份。

        对于VOB的备份，我们需要根据VOB服务器操作系统的不同来调整相应的备份流程。

        如果VOB服务器的操作系统是UNIX/Linux，那么备份过程就是在备份前lock所有VOB，然后备份VOB Storage，完成备份后，unlock所有VOB。

        如果VOB服务器的操作系统是Windows，那么在备份VOB Storage目录之前，需要先停止ClearCase服务，完成VOB Storage备份后，启动ClearCase服务后再unlock所有VOB。在Windows上，即使为了备份已经lock了VOB，但是vob_server进程仍会让VOB数据库文件处于打开状态。许多Windows备份工具都不具备能够备份处于打开状态的文件的功能。它们会跳过处于打开状态的文件，这使得备份工作毫无价值。所以，对于Windows操作系统，我们在备份VOB时，需要将ClearCase服务进程停止，保证所有VOB数据库文件没有处于打开状态。

        我们为了备份而中止ClearCase服务进程，意味着在这段时间内，ClearCase调度程序将无法运行，因此不会有任何按计划被调度的进程执行，比如每日的Scrubber进程或MultiSite的Export等复制进程等。因此我们应该合理安排备份时间与ClearCase后台调度例程之间的先后次序。在实际操作中，我们可以根据VOB备份所需的时间来定义其他调度进程执行时间。假设VOB备份需要3个多小时，那么我们可以设置从零点开始执行VOB备份进程，其他后台调度进程就设置在4点之后进行，错开各个调度进程之间的执行时间。

（未完待续）