1 简介

1.1 目的
本文的目的是介绍某公司在将软件资产从其他配置管理工具迁移到IBM Rational公司的ClearCase UCM配置管理解决方案的一些经验。

1.2 概念
在使用ClearCase之前，必需理解某些概念：

    Element 纳入配置管理的包括版本信息的配置项，包括文件与目录。
    VOB Version Object Base，存放配置项的库。
    UCM Unified Changed Management的缩写，统一变更管理模式
    Activity Activity是ClearCase UCM模式中的一个概念，通过变更集(Change Set)跟踪完成一项开发任务所引起的所有配置项的变更。在UCM模式下所有的Check Out、Check In、Add to Source Control等引起配置项发生变化的操作必须关联到一个Activity。
    Change Set Change Set记录了Activity所关联的所有的配置项的版本变更，每个Activity都有一个Change Set。
    Component 可以理解为一些代码、文档、Model等按一定的目录结构组织成的完成某些功能的可以重用的集合。这是UCM所引入的概念，Component与UCM Project相关联，UCM Project所管理的所有的Element必定从属于一个Component，每个UCM Project至少有一个Component。
    Deliver UCM的概念，是一个从开发流向UCM Project集成流或其他开发流提交工作的一个动作。
    Development Stream UCM的概念，可以理解为一个独立的开发环境，包含了在这个开发流上的Activity与修改的配置项的版本，UCM通过开发流简化了并行开发的配置管理工作。
    Dynamic View Dynamic View是对VOB的一个动态视图，VOB的变化会及时反应到Dynamic View上，每个Dynamic View都关联到一个Stream上，在Dynamic View上会有一些View的私有文件，这些View私有文件不会被同一个Stream上的其他View所见到。
    Integration Stream UCM的概念，可以理解为项目的主干，每个开发流都是集成流的一个分支，在开发流上完成工作后，再提交到主干，项目的Build环境建议采用集成流
    Project 是ClearCase UCM的一个概念，包含了配置管理所需要的一些配置信息，如果Component、Baseline，Stream等，每个Project都有一个Integration Stream。
    Project VOB(PVOB) 是存储UCM所需要的一些特殊的信息，如Proejcts，Stream，Activity及Change Sets等，一个PVOB可以包含多个Project的信息， Project的信息必须保存在PVOB中。
    Rebase UCM模式的一个操作，让当前Stream的View的内容与Integration Stream推荐基线同步。
    Snapshot view Snapshot View是对VOB的一个静态视图，将相关的VOB的选定的版本下载到本地保存，需要经常进行Update View操作以保证与关联的stream同步。
    Add to Source Control 执行将选定的文件或目录纳入ClearCase管理的动作，需要注意的是，如果要在某一目录下添加文件或目录，必须先将它所在的目录先Check out，再在该目录下执行Add to Source Control动作，而后再对当前目录执行Check in；如果正确执行完成后，该文件与目录后的类型会变为File element Version或Directory Version，如果没有将当前目录Checkout执行Add to Source Control，则在执行完成后文件的类型还是View-private File或View-private Directory，在这种情况下，该文件或目录实际上没有纳入配置管理。

2 计划与准备

2.1 计划
配置管理切换大至可以划分为以下几个阶段：计划，准备，配置库的迁移，正式使用。

配置管理切换计划的主要内容包括进度、资源等。

项目的规模与所处的阶段不同，则配置管理切换所需要的时间也不同。一个20人左右，开发进度约达到计划的一半，代码量达到50K左右的项目，从开始计划到配置管理完全切换到ClearCase，少需要3-4周时间。如果盲目的追求进度，想在1-2周内切换完成，则可能在切换后产生一系列后遗症，如版本丢失、版本错误甚至可能会有部分项目组成员抵制，从而使项目开发进程中部分工作不能纳入配置管理之下。

进度安排建议：根据项目的情况用5-15个工作日进行准备，配置库的迁移需要5个工作日左右的时间，配置管理工程师要用5-10个工作日的跟进以使项目组成员熟悉并不再需要帮助。

任何计划都有一个前提：资源，不同的资源会导致不同的进度与成本。在配置管理切换中三类资源非常重要：经过培训并且有ClearCase经验的配置管理工程师；经过培训并了解ClearCase UCM概念的项目经理与架构师；Rational工程师的及时支持。

配置管理工程师在这3-4周时间内要没有其他的任务的打扰，全部的时间应用于该项目的配置切换；每个项目在配置切换的准备阶段如果有Rational工程师的现场支持会少走许多弯路。

为了更好的完成工作，配置管理工程师必须经过系统的ClearCase的培训，同时为了提高配置管理工程师的能力，建议在内部建立一个独立的试验环境，可以让配置管理工程师从安装配置Server开始，进行ClearCase的各种功能的操作试验，以获得经验。

2.2 准备
如果决定应用ClearCase，好的计划与充分的准备会起到事半功倍的效果。一个项目从启动应用ClearCase则相对于从其他配置管理解决方案迁移到ClearCase在准备上要容易的多，包括多个版本分支的产品的配置迁移则更加困难，如果准备不充分，可能会造成多次反复、严重降低工作效率，甚至可能会造成版本错误等严重后果。

首先，要决定是应用ClearCase UCM还是Base ClearCase，UCM模式是基于Base ClearCase应用Activity管理变更的一种模式。如果项目组全部在UNIX上进行开发，比较熟悉CVS，对命令行及Shell很熟悉，项目团队配合时间较长，有专职配置管理工程师，建议应用Base ClearCase，但是需要自行开发脚本，以利于项目组成员的使用；跨平台项目、配置管理工程师是与其他项目共用的、需要对项目的进度与活动有较高的透明度等建议应用UCM模式。本文主要探讨UCM模式。

在准备的时候要确定当前项目与其他的项目的关系，以确定PVOB的建立，如果项目和其他项目的关系不是很紧密，建议创建一个独立的PVOB。因为一般PVOB不占用过多的资源。

2.2.1 配置模式

PVOB建立完成后，要根据项目的实际情况确定项目的开发模式，这里给出一些建议。

2.2.1.1 共享流模式

项目只有一个单独的集成流，没有开发流。适用于调研项目或规模较小，且目标单一，不会同时有多个变更存在的项目。比较大的项目也可以在实际项目的初始阶段建立一个UCM Project，采用共享流模式，在需求完成后，在这个Project的Component上建立Final基线，在这个基线上建立一个新的多开发流模式的UCM Project进行设计与编码。

优点：控制简单，如果设置的是Dynamic View，每个人的修改，其他人可以立即看到，不需要deliver，对有大量文档的项目较适合；不需要针对Deliver及Rebase设置大量的基线，配置管理人员的工作相对较少；同时项目配置管理的Policy也比较简单，不需要考虑太多。

缺点：如果同时支持多个不同的客户或同时有多个变更，这些变更之间互相影响，则会产生开发的混乱。

在Clearcase中共享流模式也支持同时多个用户对同一文件进行Check out操作，并在Check in时进行归并。但是如果多人对一个Element进行Check out操作时，只有一个人可以应用Reserved checkout，其他的项目组成员只能进行Unreserved Checkout。Reserved Checkout保证了开发人员是在新的一个版本上进行Checkout，只有在Reserved Checkout的人Check in之后才可以Check in并进行归并。Reserved与Unreserved的区别可见图一。