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

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

• 统一标识工件，并存入安全的配置库
• 控制和审计工件的变更
• 在项目的里程碑处建立相应的基线
• 支持对工件的并发变更
• 设置测试环境
• 历史数据迁移

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

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

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

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

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

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

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

1.1 配置库的创建

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

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

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

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

1.2 配置库的备份

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

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

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

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

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

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

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点之后进行，错开各个调度进程之间的执行时间。

2 控制和审计工件的变更

工件经过标识并存入配置库之后，需要控制什么人获准修改这些工件，还要保持修改的相关信息：什么人做的修改，什么时候做的修改，为什么要做修改。我们称这些修改的相关信息为“审计信息”。这项实践对应于CMMI过程的“配置控制”、“配置状态统计”。如果没有进行控制，那么任何人都可以对系统做修改，这对于项目工件的安全与正确性是个严重的隐患。对于工件的控制，我们可以通过权限、UCM流程来实现。至于什么人做的修改，什么时候做的修改，这可以通过ClearCase本身的版本记录信息来实现。为什么要做修改，则可通过开发人员填写的检入注释，或者是修改文件时关联的活动描述来记录。

我们通过下面的章节具体说明如何在项目中使用ClearCase来实现控制和审计工件的变更。

2.1 权限与安全

ClearCase通过以下四种类别的权限来进行安全控制：操作系统权限、VOB/View权限、目录权限和文件权限，这四种权限是逐层嵌套的。在你能访问一个ClearCase元素时，这里有几层的安全机制必须考虑到：

• 设置正确的VOB Storage权限，以便你能够访问ClearCase存储池。
• 你使用的视图是否有权限访问VOB？为了能够访问VOB，你所属的组是否在VOB的组列表中？
• 一旦你可以访问VOB，你是否有权限可以访问目录？
• 如果你可以访问一个目录，你是否有权限可以访问目录里的元素？
• 是否有ClearCase触发器限制你访问元素？

图二安全和权限示意图

ClearCase使用用户、用户组来进行权限控制的，包括User（属主）、Group（属组）、Other三个类别，每个类别的权限包括读、写、执行三种。在图三的例子中，doc目录的属主是XFSHEN\judy，这个用户具有读、写、执行三种权限；属组是XFSHEN\None，它具有读和执行权限；Other组则没有任何权限。

对于目录的权限，有个需要强调的地方。假设你要赋予某个用户组可以访问目录，并具备列出目录内文件和子目录的权限，但是不能修改目录内文件的话，那么一定记得要赋予该用户组有该目录的“读”和“执行”权限。假设只赋予“读”权限的话，会导致该用户组内的用户无法列出目录内容。

图三权限示意图

除了用户和用户组的权限设置外，ClearCase在执行特定cleartool命令时使用有层次的用户权限级别进行身份验证。也就是说，假设用户具有某元素的读、写和执行权限，但是他仍可能无法执行部分cleartool命令。用户权限级别的层次如下：

• 超级用户（如root）、ClearCase权限用户（如Windows下的clearcase_albd用户）
• VOB属主
• 文件属主
• 元数据属主
• 特定版本的创建者
• 文件属组的成员
• Other组

例如，在执行cleartool checkout命令时，你必须是文件属组成员、文件属主、VOB属主或超级用户；在执行cleartool rmelem命令时，你必须是文件属主、VOB属主或超级用户。具体cleartool命令的身份验证要求请见《ClearCase命令参考手册》。

2.2 配置管理规则

在“权限和安全”章节中，我们提到要访问元素时要明确是否有ClearCase触发器限制你的访问，触发器是我们这里要提到的配置管理规则之一。

在触发器的设置上，我们主要根据项目管理需要进行设置。例如：我们要求开发人员在做检出操作之前必须填写要修改原因，而且填写的修改原因要达到一定的文字数量，否则不允许检出；不允许项目普通成员执行删除文件或目录的操作等。

除了触发器可以对文件操作进行控制外，我们还可以通过配置规约或项目策略等来进行文件操作的限制。

假设项目组使用ClearCase的Base方式的话，我们可以通过配置规约，规定项目组成员使用ClearCase的方式。在图四的例子中，假设视图中没有检出的版本存在的话，且文件版本树中没有rel1_bugfix分支，但存在标签R1的话，那么当开发人员检出时，则创建分支rel1_bugfix；如果视图中没有检出的版本，且rel1_bugfix分支存在，则开发人员的视图显示该分支的最后一个版本。

图四配置规约图

如果项目组使用UCM方式，则可以利用UCM项目策略等设置，快速实现项目管理制度，而不用编写大量的脚本，如构件的只读设置、基线提升模式、交付制度等。

图五构件只读设置图

图六交付制度图

2.3 采用UCM方式进行日常工作

通过使用ClearCase的UCM模式，我们实现了一个可以立即用于软件开发项目的一致并基于活动的变更管理流程。UCM（统一变更管理）是IBM Rational提出的用于管理软件开发过程（包括从需求到版本发布）中所有变更的“最佳实践”流程。UCM通过抽象层次的提升简化了软件开发，从而使得软件开发团队从更高的层次根据活动（activity）来管理变更。通过UCM，一个开发活动可以自动地同其变更集（封装了所有用于实现该活动的项目工件）相关联。

采用UCM方式的好处之一，就是项目成员对于配置库的修改必须有活动关联，如果没有分配给操作用户的活动，用户就无法对配置库进行任何修改（见图七）。对于正在运行的系统而言，源码的修改获得批准是非常重要的。

图七开发人员工作流程图

如果你的项目仅使用ClearCase（也就是说，没有采用支持ClearQuest集成的项目），你可以在开始工作时创建这些活动（见图八）。他们说明了工作的目的。ClearCase活动的设计是轻量级的，开销不大。

如果你的项目在使用ClearCase和ClearQuest集成的方式，则UCM模型使用ClearQuest实体（如缺陷、功能增强请求等）来实现活动。

因此，从ClearCase角度看，活动总是预先存在的，并且活动已经被分配给你，在你开始工作时已分配给你的活动会出现你的“My Activities”列表中（见图九）。在使用ClearQuest时，活动的复杂程度依赖于进行缺陷跟踪或变更请求管理所采用的流程。

图八仅使用ClearCase实现UCM模式，在工作时创建活动

图九“My Activities”列表

2.4 配置状态统计

除了对配置项的修改进行控制外，我们还需要对控制的情况进行审计，也就是进行配置状态统计。配置状态统计，主要是记录并报告那些用于有效管理配置所需的信息。如果没有审计，相关管理人员将没有办法获知在改动过程中进入系统的内容。借助审计信息，即便对变更不加以限制，也可以随时获知什么人因为什么做了什么变更。审计信息允许我们方便的对曾经引入的错误进行纠正。

我们可以根据公司配置管理过程的需要定义审计信息的表现形式，通常包括以下内容：

• 版本变更记录
• 配置状态报告
• 版本信息
• 版本差异统计
• 代码行统计
• ……

所有上述的统计内容，除了可以借助第三方工具来展现外，我们还可以通过perl脚本调用ClearCase函数来实现（见图十）。

图十使用perl脚本实现配置状态统计报表例子