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的区别可见图一。

2.2.1.2 多开发流模式

项目中有多个不同的开发流，每个开发流都是一个独立的分支，如果项目需要还可以建立多层次的分支，支持并行开发，适于超过10人，较复杂的项目。如果项目极复杂，可以分为多层开发流与集成流，如图二。优点：可以并行开发，每个Stream都相当于一个独立的开发环境，每个人之间的工作不会互相产生干扰；可以通过Policy的设置更好的进行配置管理。

缺点：不同的Stream之间的Deliver与Rebase会产生问题；在merge时也有可能会产生问题，而且对Word等二进制文件的merge支持不好；在修改完成之后，每个Stream上的修改只有deliver与Rebase才能被其他的stream应用，不能及时反映变化；Policy的设置较复杂。

在多开发流模式下可以根据需要将某个stream设置为只读模式。

建议：可以根据需要建立一个多开发流模式的Project，但是在初期阶段不设立开发流，在进行详细设计阶段后再建立相应的开发流。

原文转自：http://www.ltesting.net