在 Rational ClearCase 和 ClearQuest 之中进行规范和定制变更管理的三个脚本

使用这些脚本实现更加灵活和有效的变更管理

Vivek Pandey
2010 年 12 月 28 日发布

本文出于以下目的考虑而去关注脚本：

只允许部分人在源控制的文件夹之间重命名或者删除文件，但是仍然限制不让每个人都有删除任意文件的权限。
每次只允许交付一个从开发流程到集成流程的 Unified Change Management （UCM）活动。
为指向相同方案的不同用户数据库实施不同的操作。

在以下的情况中您可以使用这些脚本：

第一个脚本可以在任意的 IBM® Rational® Clearcase 环境下使用，不管它是基底还是 UCM 创建。
第二个脚本只能在 UCM 环境下使用。
第三个脚本（它与 IBM® Rational® ClearQuest® 数据库相关）可以在指向相同方案的不止一个用户数据库中使用，但是您仍然需要将其与一些数据分开处理，例如选择列表，hook 许可证，记录类型可视性等等。

接下来的章节提供了所有三种脚本的细节描述。

限制重命名与删除操作

在一个安全存储库内维护配置项，就是软件配置管理的一个主要任务。您不应该允许删除任意的工件，除非真的有必要这样做。

对于 Rational ClearCase Rmname 操作有一个预操作激发器的一般实践行为，以确保没人能够有意地删除一个工件（un）。但是在实施这样一个激发器时，它甚至会限制 Rename 与 Move 操作，因为它们会内部调用 Rmname 操作。

配置所识别的另一个视图，是配置管理的一个重要方面。所以，在识别工件且确定命名习俗之后，您应该考虑到工件名不应该频繁地更改，应该控制文件夹之间文件的重新安排问题。否则，将会使得团队成员对工件的确定路径产生混淆的理解。

记住这一点，接下来的激发脚本只向特定的用户分配有重命名和删除许可证，这一点在脚本中提到过。同时，对于所有的用户仍然限制了文件删除的权限。

清单 1. Restrict_Rmname_Trigger.pl 脚本

#! /usr/bin/perl

$clearcase_user = $ENV{CLEARCASE_USER};
chomp($clearcase_user);

$pop = $ENV{CLEARCASE_POP_KIND};

$match = Check_user();
if ($match == 1)
{
 # print "User-id matching. Has permission to go ahead with the trigger \n ";
 if ($pop ne "lnname")
 {
  exit 1;
 }
 else { exit 0; }
}
else
{
 # print "User does not have permission \n";
 exit 1;
}

sub Check_user
{
@exempted_users = (‘vivek.pandey','user.alpha','user.beta');
$result = 0;
foreach $i(@exempted_users)
{
  if ( $i eq $clearcase_user )
  { $result = 1;
    return $result;
  }
}
return $result;
}

在这个脚本中，一个 Perl 程序，check_user()，将用户 ID 与已存在的列表进行匹配，如果用户拥有执行移动或者重命名操作的权限就返回结果。

您需要使用 ClearCase CLEARCASE_POP_KIND 环境变量来决定用户是否调用了文件删除或者移动操作。如果用户调用删除操作的话，脚本就会在不和用户 IDs 相比较的情况下存在，因此这就限制了删除操作。

代码清单 2 中的脚本应该在定义 ClearCase VOB 中的激发器时得到调用。

清单 2. 调用定义激发器的脚本

Cleartool mktrtype –element –all –preop rmname –execwin 
“ccperl Restrict_Rmname_Trigger.pl” No_Rmname

注意：
在定义激发器时，我们使用 ccperl 汇编器，它包含在 ClearCase 之中，这样就不再需要单独地安装适当的 Perl 版本。

在单独的交付过程中允许一个 UCM 活动

在 UCM 中，当您从开发流程交付一些活动到集成流程时，UCM 就会对集成流程创建一个集成活动。

这意味着，如果您从开发流程交付了不止一个活动到集成流程，那么对于集成流程都会创建单独的交付活动。

假设有这样一种情况，在交付任意的工作之前有多种检查的层次；因此不同的角色会使用多种流程。考虑一下图 1 之中的事例。

图 1. UCM 中的范例流程策略

点击查看大图

在这种情况下，处理多个任务的开发员在不同的 UCM 活动之间交付所有的工作到 Defect Validation 流程之中，UCM 会在目标流程之中为任意成功的交付创建一个单独的交付活动。

考虑一下这样一种情况，发布支持将一系列的活动（四个交付的活动中有两个）集成到 Integration 流程之中。在这种情况下，只挑选一些您希望交付的活动要面临很大的压力，因为 Defect Validation 流程中显示的活动还包含有您不想要的工作项。

作为方案之一，有一种进程环境让用户每次只能交付一个活动。但是没有保证所有的用户在所有的时间范围内都能遵循这一点，特别是在发布的日期临近，面临很大的工作压力时更是这样。

为了改进这样的一个进程（一次交付一个活动），您可以使用激发器脚本，Deliver_only_one_actvity.pl，如代码清单 2 所示。

代码清单 3 显示了实际的代码。

清单 3. 激发器脚本

#! /usr/bin/perl

my $from_stream = $ENV{CLEARCASE_SRC_STREAM};

# `clearprompt proceed -prompt $from_stream  -prefer_gui`;

if ($from_stream =~ /Development_Stream/)
{
   $delivered_acts = $ENV{CLEARCASE_DLVR_ACTS};
   @activities = split(/\s/,$delivered_acts);

   $no_of_activities = scalar(@activities);

   # `clearprompt proceed -prompt $no_of_activities  -prefer_gui`;

   if ($no_of_activities gt 1)
   {
    `clearprompt proceed -prompt "You can Deliver only one activity at a time from 
Development Stream" -pefer_gui`;
   
    exit 1;
   }
}

在这里，您要使用 CLEARCASE_DLVR_ACTS 环境变量来决定选择了多少个 UCM 活动从开发流程处交付。如果活动的数量没有超过 1，那么它就会存在并且不会继续交付下去。

注意：
from_stream 变量用于决定应该对什么流程应用限制规则。

该脚本应该在定义 UCM 项目 VOB 中的激发器时得到调用。

清单 4. 定义 Trigger 以允许一次只能交付一个活动

Cleartool mktrtype –ucm –preop deliver_start  -execwin 
“ccperl Deliver_only_one_Activity.pl” Deliver_Only_One_Activity

增强 clearquest 用户数据库的单独实施操作

通常来说，会有多个用户数据库会指向相同的 ClearQuest 方案。例如，一个项目开发团队可能要面对并处理来自不同客户的缺陷或者变更请求（CRs）。

出于维护客户隐私的考虑，对于不同的客户通常需要不同的用户数据库，但是它们会指向相同的 ClearQuest 方案。对于所有的客户来说缺陷或者 CR 工作流程都是相同的。

可能会有这样一种情况，在用户数据库的层次上（例如，向下拉菜单添加一个值，对于不同的用户数据库拥有不同的许可权等等）需要特定的变更，同时维护相同的方案需要实施它们。在这样一种情况之下，请注意，在实现一个客户的需求时，它不会干扰其他客户的需求。有了相同的 ClearQuest 方案，对其所作的其他更改将会反映在所有的用户数据库之中。

为了克服这一点，您可以使用以下的代码片段，其中部分的代码会根据它所影响到的用户数据库而进行执行。

清单 5. 访问控制 hook

$result = 0;
$database = $session->GetSessionDatabase();
my $userdb = $database->GetDatabaseName();
# $entity->SetFieldValue(userdb, $userdb);
if (($userdb eq "TEST1") || ($userdb eq "TEST2") || ($userdb eq "TEST3"))
{
	$result = 1;
     if (MemberOf("GroupA") == 1)
	 {
	     $result = 1;
               }
}

上面的脚本就是 Review 工作流程 Submit 操作的访问控制 hook，以下的标准得到了贯彻：

用户不应该向用户数据库提交一个 Review 记录，除了 TEST1，TEST2 与 TEST3 数据库除外。
如果有某个用户属于 ClearQuest GroupA，那么只有这个人才能够向三个数据库提交一个记录。

注意：
MemberOf() 就是另一个记录脚本，用于检查试着提交记录的用户组。但是，讨论脚本的问题，超出了本文的讨论范围。

在这里，我们使用 ClearQuest GetDatabaseName()API 来决定用户要提交记录的用户数据库的名字。

该脚本可以得到进一步的改进，以实施其他的变量，例如对于不同用户数据库的不同选择列表，根据用户数据库而变的许可权限等等。

查看 Resources 部分以得到关于 ClearCase 与 ClearQuest 的进一步信息。