|
Brian White的本篇文章阐述了统一变更管理（UCM），一个由Rational结合我们的用户开发的特殊的变更管理过程。
术语变更管理（CM）涉及到一个组织或项目用来计划、执行和跟踪一个软件系统变更的过程和工具。统一变更管理（UCM），是由Rational结合我们的用户而开发的一个特定的变更管理过程。UCM支持软件项目团队管理文件、目录、构件和系统的产生和修改。从理论上讲，变更管理过程由两个流程组成：
- 软件配置管理（SCM）
- 缺陷和变更追踪（DCT）1
SCM涉及到版本控制、工作空间管理、软件集成、软件构造、软件部署和发布过程。缺陷和变更追踪处理缺陷、增强请求和新功能被提交、评估、实施，验证和完成的过程和流程。
Rational提供了两个工具来分别支持这两个流程。首先是Rational
ClearCase®，自动化软件配置管理相关的过程。其次是Rational
ClearQuest，自动化缺陷和变更跟踪相关的过程。这两个工具合在一起，你就可以自动化统一变更管理（UCM）了。实际上，你使用ClearCase和ClearQuest几乎可以自动化任何变更管理过程，但是如果你希望更容易地支持变更管理，UCM是你最佳的选择。
在Rational，我们已经用各种方法回答了这个问题，“什么是UCM过程？”（参见下面的参考）。我们提供产品文档，一本关于ClearCase和UCM的书，以及一张多媒体CD，可以从这里free免费预定。因此，如果你已经知道一些有关UCM的内容，你可能会问，“是什么使得UCM比其它的变更管理过程更好？”在这里我将尝试回答此问题。
让我们从解释一个过程开始，它不可能适合所有的软件项目。然而，实际上如果不放在一个实际的软件开发项目环境中，将UCM描述为优于其它变更管理过程是没有实际意义的。因此，我将描述什么使得UCM不同于传统的变更管理过程。接下来你就可以自己确定这些区别如何应用到你自己的软件开发项目里。
使用UCM进行更高级别的抽象
如果你看一下软件语言的发展，很明显，在计算机科学和工程十多年来，机器代码的抽象级别有了很大的提高。在最低级别上，所有都是1和0，并且我认为非常早期的开发工程师就工作在这个级别上。很快有了汇编语言，它将1和0抽象成基本的机器指令，例如用值Y加载寄存器X。接下来的语言例如Pascal
and C，它们提供了更高次序的结构例如“if-then-else”语句。并且现在，在今天，我们开始认识到可视化“编程”的潜力。通过模型化软件系统的行为，我们可以让代码为我们而产生。通过引入这些抽象，开发者进行更复杂软件系统的编程会变得更容易和更快速。
类似的事情发生在配置管理工具的演变上。最初，配置管理工具只是由保存版本的存储库组成：一个文件和目录的内容在给定的时间点上存储和确定，并且在需要时可以重现取回。然后到了允许用户管理工作空间的工具：一个特殊任务或活动所选择的文件和目录的特定版本集。并且，随着较作为低级别的抽象，例如存储库和工作空间，变得普通和广泛被接受，较高等级功能可以放在顶端，以简化变更管理过程。UCM正是做这些。让我们看看UCM包括的三个关键抽象：项目，构件基线，和活动。
项目
通常，软件开发团队被组织成项目。这些项目，依次还有子系统，等等，因此一个项目可能非常大，或者是非常小。从变更管理的观点来看，项目的组织有三个目的：
- 首先，项目定义了团队成员。这对安全目的和协助目的很有用，这两点对好的变更管理非常关键。
- 其次，项目限制了团队需要知道的文件和目录的范围。也就是说，所有的文件和目录保存在库里，项目确定了开发者被分配的精确子集，那是项目需要考虑的方面。
- 第三，项目为团队成员所执行的工作确定了一个公共集成点。
这些听上去非常平凡，但是UCM关键的优势在于在ClearCase和ClearQuest执行时，项目是一个物理对象在这个配置管理系统里，它规划了实际的项目，允许一个比可能的更高程度的自动化和安全，如果project项目不是配置管理工具的概念之一。例如，当新的开发者加入到一个UCM项目时，他们自动地被给定一个预先配置好他们所需要的文件和目录的正确版本的工作空间。
构件和构件基线
UCM里第二个关键的抽象是构件和构件基线。大多数版本控制系统包括存储库的概念，存储库是文件和这些文件版本的集合。一些工具，例如ClearCase，也将这些文件组织到目录并保存目录和目录版本。几乎所有重大的开发工作都包含大量的文件，这些文件包含的代码需要在开发下构造该系统。这些文件组织到目录里，并且这些组织经常列成系统的软件架构。在传统的配置管理系统中，这些关键的目录和其它的目录是不会被看成是同样的。然而，为了区别并保存这些目录，UCM引入了一个component构件的概念。一个UCM构件简单来说，是一个由同一个构件根目录下的文件和目录组成的目录树。
为什么UCM做这些？
UCM构件的主要优势，和项目一起，可以更好地进行自动化。最好理解的方法就是查看关于基线的概念。基线定义了一组相关联的文件版本。基线，换句话说就是，选择在构件里的每个文件的一个版本。几乎所有版本控制工具都声明支持基线，但是如果你走近观察，你通常会发现他们实际上只支持打标签的概念。打标签是一个过程，通过此过程，你可以选择一个标签名，然后将此标签名附在一个或多个文件版本上通过将相同的名字粘附在许多不同的文件版本上，你就可以得到一个基线。
使用这种方式进行基线化的问题在于，没有由标签名所暗指的语意上的含义－－除了那些提示你如何使用这个工具。你不能查看标签和知道特定关联到它的文件。实际上，这告诉你调查哪些文件有这些标签，同时，标签能够关联到新的文件，移动到新版本，或者从选定的文件删除。当然，你可以执行控制并锁定执行你自己的标签，但是UCM基线为你解决了这些问题。这些基线从语义上描述了对象定义的UCM构件版本。通过使用这些版本，你可以确定这些基线没有从你那里变更。一旦创建，UCM基线是不可变的，并且能用于定义更高级的配置。一个完整的系统，例如，能够有一组构件基线进行组合。
活动
可能关于UCM最有特色的事情就是基于活动的变更管理模型。这意味着什么？它意味这对文件的变更是来自变更的理由。比如，假设你正修改一个缺陷和执行一个新功能。无论什么时候你变更一个文件，你确认你正执行的变更的原因是通过在检出时声明一个活动。一个活动可以是一个缺陷，增强请求，或者是简单的一行变更描述，这取决于你的缺陷和变更跟踪过程需要多严格。UCM支持所有类型的活动－－以及任何其它你选择自己定义的活动。
基于活动的变更管理最主要的优势在于如果不关联到一个原因就不能检出文件。第二个优势是变更被集成（或提升）为一个单一、一致的整体。大多数时候，当你进行一个变更时，需要修改多个文件。例如，如果你正在修改一个缺陷，你可能需要修改C文件和一个头文件。你经常需要修改很多文件。在UCM里，所有你必须做的事情都需要选择“活动”来为所有的文件记录所有新创建的版本。如同为项目和构件所做的，UCM引入了一个物理活动对象到配置管理系统，配置管理系统映射到一个真实世界的对象：“工作单元”。这很明显，马上可以得到的好处是：例如，当你结束一个给定的任务时，你能在同一时间通过简单地检入活动而检入你的所有工作。
然而，此外，还远没有达到自动化和报告上的受益。UCM通过系统将变更转移到活动级。也就是，当你准备集成你的变更时，你可以“提交”活动。这是有别于其它配置管理方法，其它配置管理方法需要合并一组文件，或手动地将材料单发送给某个人，然后他将会列出你的变更里所包含的版本。
实际上，基于活动的方法最大的好处是活动和基线在一个构件已经被许多个人修改之后，创建一个新的基线。通过活动和基线的使用，就可能自动化过程，确定这个基线和其它基线的差异。两个基线之间的比较，不仅产生了从一个基线变到另一个基线发生变化的文件列表，而且也产生了发生变化的活动列表！这有非常大的好处：你可以自动地产生发布说明，在每晚构造后帮助测试人员确定并运行必要的回归测试集，等等。
基于客户系统
本文提供了仅仅是UCM的很多能力和优势的一点体验。基本上，通过将真实世界的对象引入到配置管理系统中，管理软件项目上变更的此过程－－自动地使用Ratioanl
ClearCase和Rational ClearQuest－－提高了抽象的级别和自动化的可能性。项目，构件基线，和活动。如果你是Rational
ClearCase 长期的用户，你可能在你的ClearCase
定制里发现一些UCM过程。很多基于脚本的变更管理过程，在ClearCase上构建，在定义什么是UCM上扮演了一个关键角色－－并且将会在确定它将会成为什么上继续进行下去！
参考
Brian A. White (由 Geoffrey M. Clemm介绍), 软件配置管理策略和Rational
ClearCase：实践指南 (TheADDP9 Object Technology Series).
Addison Wesley Professional, 2000.
Rational
Change Management CD (Free Order/View Request Form)
脚注
1也称作变更请求管理（CRM），不要与客户关系管理混淆。
编者注：文章最初发表在The
Rational Edge上。
参考资料
- 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
|