Base ClearCase与ClearQuest的集成

2005 年 8 月 18 日

Rational ClearCase是一个业界领先的软件配置管理工具，Rational ClearQuest则是IBM Rational在变更管理和缺陷跟踪方面的软件。业界对于变更管理软件和配置管理软件的集成有着强烈的需求，因此IBM Rational也提供了ClearCase和ClearQuest集成的功能。

1 概述

Rational ClearCase是一个业界领先的软件配置管理工具，Rational ClearQuest则是IBM Rational在变更管理和缺陷跟踪方面的软件。业界对于变更管理软件和配置管理软件的集成有着强烈的需求，因此IBM Rational也提供了ClearCase和ClearQuest集成的功能。

所谓Base ClearCase和ClearQuest的集成，就是将ClearQuest中的变更请求(Change Requeset)关联到一个或多个ClearCase中元素(Element)的版本(Version)上。一个变更请求可以被关联到一个或多个版本上，实施变更的这些版本的集合被称作变更请求的变更集(Change Set)。一个版本可以被关联到一个或多个变更请求，这些变更请求的集合被称作版本的请求集(Request Set)。

集成对于不同的角色，有以下不同的功能：

一个项目经理指定在什么情况下需要让用户关联版本到变更请求。也可以指定关联变更请求的VOBs，branches，以及element types。

ClearQuest的管理员添加ClearCase的定义到ClearQuest的schema中。这使得变更请求可以显示与它关联的变更集。

使用ClearCase进行开发的人员，可以在Check Out或者Check In一个版本的时候，将这个版本关联到一个或者更多的变更请求上。也可以查看一个变更请求的变更集。

在这篇文章中，我们将对Base ClearCase与ClearQuest集成的设计原理和运行环境的搭建与设置进行介绍，最后再提供一些操作范例。

2 基本概念

2.1 集中方式(Central Server)

所谓的Central Server就是将所有的脚本文件及配置文件放在一个目录，当进行集成的时候，ClearCase就会在这个目录中寻找配置文件（config.pl）、cqcc_launch脚本以及其他的代码，而不是使用本地默认目录的相应文件，因此提高了安全性和可维护性。与之对应的本地方式(Local Server)则是使用本地ClearCase目录中的配置文件、脚本以及其他代码。

2.2 批处理(Batching Enabled)

就是将一个ClearCase操作中的所有与ClearQuest相关的操作，记录到一个批处理文件中，ClearCase操作完成之后，再将这些操作一次性写入到ClearQuest中。从而降低了登陆ClearQuest和在查询ClearQuest的次数，大大的提高了性能。

2.3 序列(Batching Series)

批处理序列是将批处理的概念进一步扩展的产物。ClearCase认为所有进行的ClearCase都是在一个批处理当中，它记录所有与ClearQuest相关的操作到批处理文件当中，以便在以后的某个时间完成与ClearQuest相关的操作。

2.4 检入后提交(Postcheckin commit)

就是在ClearCase的Check in完成之后，再进行ClearQuest的操作。一般的情况下，在ClearCase的Check in操作完成之后，才进行与ClearQuest相关的操作。这样在Check in操作失败的情况下，会造成ClearCase和ClearQuest的数据不一致。启用此功能则可以避免这种错误。

2.5 自动关联(Auto-association)

就是在将变更请求关联到某个版本的时候，不需要手工选择，而是靠预先设置的请求ID或者根据ClearCase操作的注释自动提取请求ID，来决定关联的请求。

2.6 使用CQWeb方式的集成

在本地没有安装ClearQuest，或者不愿意使用本地的ClearQuest的情况下，可以使用CQWeb的方式使用CQWeb Server上的ClearQuest来实现ClearCase和ClearQuest的集成。

3 何时采用Base ClearCase

我们知道UCM是一种对版本控制的配制管理流程，而UCM是基于Base ClearCase的管理流程演变而来的。因此掌握并了解Base ClearCase的管理就显得至关重要。Base ClearCase包含了一系列功能，它们能够使开发人员做到并行开发，项目管理者也能通过制定相关的规则来使开发工作有序的进行。

在开发过程中，Base ClearCase应用"分支(Branch)"的方法来允许开发人员进行并行开发。任何在配制管理下的元素(Element)，例如：文本文件，程序原代码等，都会生成一个主分支，而主分支下还可以有多个下属分支，它们的作用是用来支持在主分支上的开发。Base ClearCase 允许创建复杂的分支体系。在开发过程中，通过视图（View）可以访问特定元素集的特定版本，而这通过修改视图的规则(Config Specification)就可以实现。UCM也使用"分支"的方法，但是这些分支不需要用手工来操作，而是通过"流(Stream)"来实现，通常情况下，一个项目存在一个集成流和多个开发流。

在项目管理方面，我们通过对项目的源文件打基线(Baseline)来呈现项目早期较稳定版本的雏形，并且基线可以用来连接一系列相关的源文件，比如像源代码，测试计划等等。UCM自动完成基线的创建，而Base ClearCase则通过对元素(Elements)的版本打标签来创建基线。

通过以上对UCM和Base ClearCase的比较，因此在一个项目不是很大，并且业务流程相对简单的情况下适合用Base ClearCase。

4 运行环境的搭建与设置

4.1 运行环境的搭建

在Base CCCQ集成的过程中，运行环境的搭建尤为重要。

图 (01) 系统结构图

首先，需要在ClearCase客户端和ClearCase注册服务器安装ClearCase。在ClearQuest Unix服务器和ClearQuest Windows服务器安装ClearQuest。准备数据库服务器。在ClearQuest Unix服务器上配置好DBSet，并添加User DB。之后就可以配置集成了。

4.2 ClearCase与ClearQuest集成的配制

集成的配置需要在ClearCase和ClearQuest上分别进行配置，才能完成。在ClearCase侧，需要对VOB配置。当对一个VOB配置了集成之后，针对与这个VOB的ClearCase相关操作（例如CheckOut, CheckIn）都会激发脚本对ClearQuest数据库的访问，进而完成Base CC和CQ的集成。

在ClearQuest侧，需要在数据库中添加ClearCase的定义，只有加入了定义之后，数据库中的请求的变更集才能够显示出来。

下面具体介绍配置过程。

4.2.1 将ClearCase package加入到一个ClearQuest DBset

由于ClearQuest schema包含了一些与多个ClearQuest user databases相关联的特性，例如数据记录的类型，区域，和形式。在开发人员将ClearCase中文件的版本与ClearQuest用户数据库中的变更请求相联系的时候，必须将ClearCase的特性也加入到ClearQuest schema，此过程要在Windows端完成且过程如下所述：

• 开始 -> 程序 -> Rational Software -> Rational ClearQuest -> ClearQuest Designer
• 在ClearQuest Designer中，点击Package -> Package Wizard
• 在安装Package向导中，找到ClearCase 1.0和ClearCase Upgrade 1.0，如果这些Packages没有列出，则点击"More Packages"，并将上述的两个Packages添加到列表中。
• 选择ClearCase 1.0 Package并点击"下一步"
• 选择一个将会应用ClearCase 1.0 Package的schema e.g. Defect Tracking，点击"下一步"
• 选择数据纪录的类型并点击"完成"
• 选择File -> Check In来保存schema的最新版本
• 选择Database -> Upgrade Database把schema的最新版本升级到ClearQuest user database中