UCM狂热者：从Base方式转移到UCM ClearCase

你想过将ClearCase由base方式转移到UCM方式吗？你的base配置支持你的组织当前的使用模型吗？你可能想考虑何时决定转移到UCM方式，这里有来自Christian Buckley和Darren Pulsipher的一些想法。
什么是统一变更管理(UCM),以及它如何应用于IBM? Rational ClearCase?

UCM被发展出来，使得人们从一个有效的使用模型开始使用ClearCase变得更容易了。这是由于"base" ClearCase配置非常灵活，以至于很多组织发现使用这个软件比较困难。为了让ClearCase对于他们的特殊需求更加有用，他们编写了自己的脚本和过程。UCM在确定ClearCase使用模型的大多数公共元素上进行了努力，并创建了使应用软件更加有效的对象和方法。

如果你现在正在运行base ClearCase方式，你可能在某些点上考虑升级至UCM。但是从什么地方开始呢？涉及哪些内容呢？区别在什么地方？在考虑从你当前的ClearCase系统迁移到UCM系统之前，你应该首先理解你当前的使用模型－－以及你的组织自从安装以来如何使用Basic ClearCase对象。这个变化的过程非常类似于第一次迁移到ClearCase系统的过程。对于任何新的项目，你需要弄明白在你可以向前走时你处于什么位置。

首先，你应该回顾一下当前使用的基本ClearCase对象。通过回顾当前的对象，你将能够了解你的基础装置和UCM方式之间的区别，更好地理解新的UCM对象带给你的ClearCase系统的新功能。进行此变更的大多数组织发现，他们已经编写了许多自己的脚本来执行由一些UCM对象包含的功能。象这样的一些情况，采用UCM对象就会很好。这会使你受益，因为此时ClerCase与你的定制开发有相同的功能，在系统里你会有更少的必须支持的脚本，使得你可以花更多的时间关注实际的工作。

基本的ClearCase对象
如果你已经完成了一个配置管理(CM)计划，同样可以做。如果你还没有一个计划，请参见IBM Rational Unified Process 方法论选择一个合适的模板。一个好的配置管理 (CM)计划应该包括非常概括的工作流程条款，和特定的ClearCase规划。如果你已经有了自己系统详细的规划，将会发现UCM的变化将会相当直接。至少你将会容易地能够看到无论是否是UCM对于你的实施都是一个很好的适合。那就是你希望有一个对于已有对象和你当前的对象的清除的理解－－仅仅因为UCM是可用的，不必要地意义你将会使用它。

UCM主要是对你已经一直在使用的base ClearCase 对象增加了额外的对象和工作流。因此，在你着手这些变更前，首先看一下关于当前使用的ClearCase对象的一些问题：

VOB（版本对象库）
版本对象库（VOB）在UCM中如同在base ClearCase使用模型中一样重要。你有可能在你当前的系统里继续使用相同的VOB结构。当你可能改变少量东西使其在UCM中更有效时，你可能最希望什么也不做。当然，你将会需要回答一些有关你的VOB结构的基本问题，这些问题的大多数可能已经在你的配置管理计划里进行了回答：

你的VOBs是如何计划的？
你有admin VOBs吗？
VOBs之间的关系是怎样的？
在VOBs里包含哪些种类信息，以及它们的目录是如何组织的？
视图（View）
UCM使用视图做一些有趣的事情。他们通常较之于基础ClearCase方式执行有更长的持续时间。回答关于视图如何创建和删除是很重要的。另外，配置规格（config specs）自动地在UCM里产生，并且它们可能不是你所希望的。重要的是你也可以描述配置规格，因而理解从原有旧系统到新系统的映射。问问你自己：

谁能创建视图？
视图创建的频率是如何的？
视图创建是自动地还是手动地？
视图保留多长时间？
什么时候删除视图？
配置规格是自动创建的吗？
配置规格是共享的吗？
标签（Label）
标签有太多种不同的使用方法，可以使你变得头晕。列出关于标签的所有可能问题是不可能的，但是如果你是负责任地并构建了一个表，这个表包含了在你的系统里的每种标签类型的信息，那你就是处于正确的道路上。在UCM里使用标签会有助于UCM使用模型。理解下面的问题总会是好的：

标签如何使用？
什么时候使用标签？（构造，合并，工作流控制）
你的标签命名方案是什么？
当标签不再被需要时，如何废弃和删除？
分支（Branch）
如果你正在使用base ClearCase而没有使用分支，那么你可能还是忽略下面的问题比较好，因为实质上你还没有一个base ClearCase的使用模型。如果是这种情况，你可以直接转换到UCM模型，而不用从你的当前模型进行映射。实际上，无论你当前有什么都必须抛弃掉。

如果在你的模型里有分支，那么你有许多工作要做。UCM分支模型使用流的概念，我们稍后会讨论。有可能，你的分支模型将会彻底被抛弃。然而，另一方面，你的使用模型可能仍然是可用的。确保你花时间来理解下面的问题：

什么时候创建一个分支类型？
你的命名约定是什么？
什么时候元素移动到分支？
你的分支策略是什么？
有多少人在同一个分支上工作？
你有一个集成分支吗？
你在“main”分支上做什么？
你要让你的分支过时效吗？
什么时候分支被弃用和删除？
合并（Merging）
与你的分支一样，你需要花一些时间在本节里理解关于合并的问题。UCM有集成点和新的命令来处理从一个分支到另一个分支的代码合并，这需要通过称为提交和变基的两个概念来完成。理解为什么合并以及何时进行合并是非常重要的。问问你自己：

什么时候进行代码合并？是由一个事件引起触发？还是由时间引起触发？
代码是自动合并还是手动合并？
谁对代码合并负责？
允许从集成分支合并到开发分支吗？
从一个开发分支合并到一个集成分支的频率是怎样的？
触发器（Trigger）
在大多数的base ClearCase系统中，触发器是非常重要的，因为他们有助于工作流程和过程控制。UCM有一些方针，包括了ClearCase触发器的使用。确保你的配置管理计划描述了你的触发器和使用它们的VOB。理解这些问题是重要的：

你使用的触发器是什么，为什么要使用它们？
哪些VOB使用的哪些触发器？
　

UCM中的基本对象
Base ClearCase提出了一些很抽象的概念，例如分支，标签，超链接，元素，视图和版本对象库，UCM作出了更高级别的抽象，我们每天用于进行开发，集成和提交产品。这些更高层的概念是：

项目（Project）
流（Stream）
活动（Activitie）
基线（Baseline）
构件（Component）
如果你已经使用base ClearCase 有一段时间了，你会很快发现这些概念已经存在你的系统里了，要么是在文档中，要么在脚本中。可以把它认为是你的才华的一个证实，软件现在提供了你曾经创建脚本去做的所有事情－－现在你可以继续轻松下来，使用这些可利用的东西。

项目（Project）
项目用于为一组人在一个单一的项目上提供工作。它可以是一个产品的发布，一个完整项目的子系统，或者是集成一些产品形成一个套间。项目包含了一个集成流和零个和多个开发流。这是项目必须的开始计划。当开始创建项目前，尽管你需要和市场人员、软件开发团队、质量保证人员坐下来讨论，同时技术方面的作者开始确定你希望如何一起工作。

有关项目的ClearCase 命令包括：mkproject, lsproject, chproject, 和rmproject。

流（Stream）
流可以比喻成开发的分支。流基本上是由元素的特定版本组成。普通分支和流主要的区别是在流里保存了附件的信息。比如，流里包含了基线，和一组活动。它也可以包含和其它流的关系，比如父流。基线，加上活动集，决定流里包括元素的哪些版本。

图1：流的例子

在图1里，有两个活动－－活动1和活动2－－已经添加到了流里。基线由那些在图里显示为粗体线条的元素版本表示。两个活动包含表示为不同的模式的元素版本。

流有两种基本的类型：集成流和开发流。对项目有一个且只有一个集成流 。在非常简单的项目里，开发者可以在集成流里做变更，工作在流里的每个项目成员只要一有检入，就会看到所有其它的变更。更复杂的项目可能有一个和更多级别的开发流，它们始于集成流的不同基线配置。在此情况下，开发者在其唯一的开发流上进行“个人”工作，并且项目成员不会立即看到彼此的工作。一旦开发者完成了他们自己在开发流上的工作，并准备共享给其余的项目成员时，开发流的内容被“提交”到集成流上。想像集成流是把来自开发流的所有变更集合在一起。

图2：集成流的例子

有关流的ClearCase命令包括： mkstream, lsstream, chstream, 和rmstream。

基线（Baseline）
基线代表了用于开始一个流和变基一个流的元素版本。一种查看基线的简单方法是把它们和标签进行比较，困难在于附加信息（包括关系）保存在基线里。基线是很多活动的起点，比如创建流，变基流，等等。

有关基线的ClearCase命令包括：mkbl, lsbl, chbl, rmbl, diffbl, setplevel, 和cleardiffbl。

活动（Activitie）
在ClearCase UCM项目里对任何元素的所有的变更必须关联到一个活动。一个活动是你的团队成员工作的基本单元。它有以下这些构件：

一个标题（ID）
一个创建者
一个变更集（变更元素的集合）
一个相应的流
如果你正在使用IBM Rational ClearQuest，一个活动通常联系到一个缺陷或一条增强请求。

有关活动的ClearCase命令包括：mkactivity, lsactivity, chactivity, 和rmactivity。

构件（Component）
构件允许你组建一组相关的目录和文件元素在一起，并且把它们和UCM项目进行绑定。一个构件被开发、集成，并且其所有的部分是一起发布的。所有的项目必须有一个和多个构件，并且在项目间可以共享构件。然而，一个构件不能跨越多个版本对象库（VOB），最大的构件大小就是它的版本对象库（VOB）。关于构件的其它内容包括：

元素不能从一个构件移动到另一个构件。
一个元素只能存在一个构件里。
一旦创建了一个构件，你不能重新组织它到子构件里。
预先计划构件是非常重要的。一个策略是：将要共享给其它项目的所有元素置于同一个构件中，或放到构件组中。

有关构件的ClearCase命令包括：mkcomp, lscomp, 和rmcomp。

文件夹（Folder）
一个文件夹是一个项目或多个项目包含信息的容器。文件夹可以包含其他的文件夹，以及任意数量的项目。你可能在你的VOB中一直在使用目录作为base ClearCase中的某些对象种类的一个文件夹。现在文件夹是第一个类对象，作为替代，你可以使用它们。

有关文件夹的ClearCase命令包括：mkfolder, lsfolder, rmfolder 和chfolder。

有用的UCM命令
理解UCM对象是将你的当前过程映射到UCM的第一步，但是为了有助于你的规划，还有一些你应当很好了解的常用命令。这些是基本的命令，可能是开发者经常使用的，理解什么时候使用这些命令是非常重要的。

工作在活动上
在检入或检出文件前，开发者需要设置一个活动到当前的视图。活动将跟踪在视图里发生的变化。所有的变更保存在一个变更集里。当提交活动时，变更集关联到这些提交到集成流里的活动，因此团队里的每个人能看到这些变更。

提交变更
一旦在一个活动上结束工作，你可以提交你的变更到默认的集成流（父流），或者提交到任何其它的你选择的流。流可以接受或拒绝变更，这取决于在团队里建立的方针。提交活动的命令是：

cleartool deliver －－ 将元素的变更从一个源流提交到目标流。提交的状态也可以从此命令得到。

当提交开始时，它创建一个特殊的活动提交变更到集成流。活动的创建有助于管理任何可能的合并冲突和解决措施。提交可以分两步完成，或者是在一个单独步骤中完成。第一步是执行变更元素的合并。第二步确定变更并标识活动的完成。你可以通过使用complete标记来强制一步提交完成。

变基工作空间
你可能会阶段性地从集成流变基你的流。记住－－你的开发流通常会等待很长时间。你会阶段性地需要从你的团队成员的活动上得到更新。基本上，在ClearCase变基命令只做如下工作：提供（并然后变更）其它团队成员已经提交到一个集成流上的活动。

cleartool rebase -- 变更流的配置

变基流时是一个多步骤的过程，很象提交活动。你可以从集成流集成代码到开发流，这包括移动标签并解决合并冲突。如同提交命令一样，-complete可以用于将自动创建的活动标记为已完成（换句话说，强制进行一步变基）。

作为一个配置经理，你最好提供推荐基线，来让开发者能变基他们的开发流。例如，一个稳定的构造可以放到推荐的基线列表上，使开发者能够看到他们正在从一个在给定时间上的代码开始工作。

将两个世界连在一起
由于使用 base ClearCase，很多UCM模型的概念对于你已经做的可能不是很困难。现在主要规划的是什么是UCM要做的。接下来你能可以检查一下从整个UCM中得到的不同可用模型间的区别。这不是你能在两个小时内做到的－－正如我们所概述的，你会需要花时间来构建一个完整的配置管理计划。你也需要彻底地详细说明你目前在使用什么，以及你想使用UCM做什么。

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