《ClearCase在实际项目中的应用（一） 》请见http://space.itpub.net/13180590/viewspace-351768。

ClearCase在实际项目中的应用（二）

Judy Shen

2        控制和审计工件的变更

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

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

2.1    权限与安全

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

l        设置正确的VOB Storage权限，以便你能够访问ClearCase存储池。

l        你使用的视图是否有权限访问VOB？为了能够访问VOB，你所属的组是否在VOB的组列表中？

l        一旦你可以访问VOB，你是否有权限可以访问目录？

l        如果你可以访问一个目录，你是否有权限可以访问目录里的元素？

l        是否有ClearCase触发器限制你访问元素？

图二安全和权限示意图

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

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

图三权限示意图

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

l        超级用户（如root）、ClearCase权限用户（如Windows下的clearcase_albd用户）

l        VOB属主

l        文件属主

l        元数据属主

l        特定版本的创建者

l        文件属组的成员

l        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    配置状态统计

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

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

l        版本变更记录

l        配置状态报告

l        版本信息

l        版本差异统计

l        代码行统计

l        ……

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

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

（未完待续）