posts - 11, comments - 3, trackbacks - 0, articles - 0
  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理

Base ClearCase与ClearQuest的集成(转)

Posted on 2006-08-09 17:04 eddy liao 阅读(405) 评论(0)  编辑  收藏 所属分类: SCM
http://www.chinaitpower.com/2005September/2005-09-13/205598.html

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中

4.2.2 在ClearCase VOBs上安装触发器(Triggers)

CCCQ的集成应用到了针对cleartool checkin, checkout和uncheckout操作的触发器,触发器的安装与配制需要在Windows端配制,该Windows的Registry Server必须与UNIX上建VOBs的那台Server指向同一台Registry Server。具体配置过程如下所述:

4.2.2.1 同步UNIX与Windows上的ClearCase Regions

1) 在Windows上新建一个Region,名称与需要同步的UNIX上的Region名称相同,这时UNIX上的Region就在Registry Server上注册了。

2) 运行 -> cleartool -> mkregion -tag <UNIX region>

3) 开始 -> 程序 -> Rational Software ->

4) Rational ClearCase'Administration'Region Synchronizer


图 (02) 导入Unix服务器上的VOB

5) 选择需要同步的Windows Region和UNIX Region, 在Import Type一项上选择"VOB Tags"并且选中"Show full storage directory paths.

6) 在"Unix VOB tags not found in the Windows region"列表中选择需要引入的VOB,点击"Import",这时"Create VOB Tag"对话框会显示出来。在"Global Storage"一项中输入在UNIX服务器上的VOB的网络存储路径,并且在"Hostname"一项中输入在Region内能够解析的主机名。


图 (03) 创建Tag

4.2.2.2 将一个VOB安装上Trigger

当一个VOB被引入(Import)后,我们可以对其安装Trigger 在ClearCase中,点击开始 -> 程序 -> Rational Software'Rational ClearCase'Administration'Integrations'ClearQuest Integration Configuration. 这时出现如下图所示的对话框。


图 (04) 应用Trigger

在"ClearCase - ClearQuest Integration Configuration"对话框中,我们可以看到所有在UNIX服务器端建立好的VOBs,并且可以对其中任何一个VOB安装trigger。在这里,我们对VOB int4安装Checkout和Checkin的trigger。Trigger的配制文件在config.pl中有详细说明,关于trigger选择的详细内容可以参看上一章节。

提示:

  • 触发器使用config.pl配制文件来控制本地集成的配制参数。当选择V2触发器时,配置应用程序会将config.pl文件路径设为CQCC/config.pl,在这个路径中CQCC代表了本地的cc-home-dir/lib/perl5/CQCCTrigger/CQCC这个路径,用户可以根据需要将这个路径改变为一个UNC路径,因此所有的集成操作将调用一个中心配制文件config.pl。
  • 在安装触发器时,只有VOB的所有者才可以对自己创建的VOB安装触发器。如果一个用户e.g. Harry登陆Windows,他想对Andy在UNIX上创建的VOB安装触发器,这时会出现"无法得到触发器类型"等警告。如果Harry希望可以对VOB安装触发器,那么需要执行以下两步:
  • 在DOS模式下运行Runas /user:RATIONALCC\Andy cmd.exe命令,这个命令将以Andy的身份打开一个DOS窗口,并提示输入用户名和密码。
  • 在验证通过登陆后,另一个DOS窗口将会打开,在这个窗口中,运行"cqconfig"来以Andy的身份在VOB上安装触发器。

4.2.3 核心文件config.pl的配置

config.pl文件的配置在Base ClearCase与ClearQuest集成的操作中起到重要的作用。config.pl文件中包含了一系列变量及参数的设置,设置的描述,以及在哪里可以配制这些参数(是在config.pl文件本身中设置还是在系统环境变量中设置)。

config.pl文件在不同操作系统上的存储路径:
Windows:C:\Program Files\Rational\Clearcase\lib\perl5\CQCCTrigger\CQCC\config.pl
UNIX: /usr/atria/sun5/lib/perl/CQCCTrigger/CQCC/config.pl

下面就一些重要的参数配置进行详细的说明:

4.2.3.1 定义用户数据库

&SetConfigParm("CQCC_DATABASE_ENTITY_LIST","SAMPL: defect");
CQCC_DATABASE_ENTITY_LIST参数定义了一个或多个数据库和数据库所支持的数据纪录类型。当定义多个数据库时,参数的使用格式为:dbname1: entity1,entity2; dbname2: entity3,entity4。值得注意的是数据纪录类型必须为在schema中已定义好的内容。

4.2.3.2 定义DBsets

&SetConfigParm("CQCC_DATABASE_SET", "<db_set_name>");
在ClearQuest中,当建立有多个DBsets时,即有多个schema存储空间时,CQCC_DATABASE_SET参数用来指定一个当前可以使用的schema存储空间。

4.2.3.3 选择集成模式: 文本模式或图形模式

&SetConfigParm("CQCC_GUI_ENABLE", "OFF");
此参数是一个开启Perl/TK GUI图形界面的开关。如果设置为"ON"(默认情况下),那么图形界面会在需要的情况下显示,例如,在运行xclearcase时。如果设置为"Always",那么图形界面会在命令行操作的形式也显示。如果设置为"OFF",那么图形界面将永远不显示,因此只可以用命令行操作。

4.2.3.4 开启DEBUG模式

&SetConfigParm("CQCC_DEBUG", "1");

此参数用来控制在运行时模式下DEBUG报告的输出级别。0 - 代表没有输出;1 - 代表基本输出(针对高级别的操作);2 - 代表细节输出。

提示:其他参数设置的详细说明请参看config.pl文件。

4.2.4 执行Base CCCQ集成的最后检验

此时,根据以上所提供的信息,我们应能够完成cqcc检验,检验ClearCase与ClearQuest是否能够很有效的结合,并可以开始完成一些简单的操作。

在UNIX客户端运行:cqcc_launch -test

此时,cqcc_launch命令将会调用config.pl里的参数并试图连接ClearQuest,如果连接成功,exit_status会显示0,否则将显示1(如下图所示)


图 (05) 验证配置


5 在Windows的平台上的操作范例

可以说,Base ClearCase的基本操作,就是Check Out和Check in两个操作,下面就简单介绍一下这两个操作。

5.1 Check Out

1) 在ClearCase Explorer中,选中一个文件,进行Check Out操作。如果是配置完成后第一次进行操作,需要输入ClearQuest的用户名和密码。


图 (06) 登陆窗口

2) 登陆成功后,就会出现QSW(Query Association Window)窗口,显示满足条件的缺陷。选择缺陷,点击Association按钮,可以将其放到上侧窗口中,点击OK,即可完成关联。


图 (07) 关联窗口

3) 关联成功后,在ClearQuest中打开相应的缺陷,在ClearCase页中,可以查看到关联的文件。


图 (08) 在ClearQuest中查询关联的文件

4) 在ClearCase Explorer中右键点击被关联的文件,选择版本属性,查看被关联的缺陷。


图 (09) 在ClearCase中查询关联的问题

5.2 Check In

1) 在ClearCase Explorer中选中文件,进行Check Out操作,弹出QSW窗口。


图 (10) 关联窗口

2) 在ClearQuest中查看被关联的文件。


图 (11) 在ClearQuest中查询关联的文件

3) 在ClearCase中查看被关联的缺陷。


图 (12) 在ClearCase中查询关联的文件


只有注册用户登录后才能发表评论。


网站导航: