中国 [选择]

本文内容包括：
	概述
	UCM过程
	设置Tivoli
	小结
	词汇表
	参考和引用
	参考资料
	关于作者
	对本文的评价

相关链接：
	Rational 技术文档库
	Rational Edge 电子月刊中文版

developerWorks 中国 > Rational >

使用 Tivoli 和 Rational ClearCase UCM 发布软件

文档选项

未显示需要 JavaScript 的文档选项

级别：初级

Kartik Kanakasabesan, IBM

2005 年 12 月 22 日

IBM Tivoli 的Configuration Manager是一个对IBM Rational ClearCase中的代码进行分段进阶和部署的有效解决方案。Tivoli和ClearCase无缝地进行协作，提供了发布和跟踪能力，并能够有效管理从分段进阶代码库到目标系统的部署过程。

概述

介绍

顾客面对的一个典型问题是在ClearCase®的框架下缺乏开发能力。测试和部署能够从开发追踪软件资产（双向地），仍然是一些客户要面临的一个巨大的问题。为了管理和控制部署过程他们必须利用其它产品或建立自己的产品。Tivoli®提供了解决这一需要的部署能力。在整个开发-测试-生产的生命周期中，迅速的部署是提供软件资产管理的前提步骤。

自IBM®收购Rational®以来，Tivoli和Rational品牌一直在如何相互补充各自的解决方案方面合作。Tivoli的配置管理软件发布方案满足了大多数ClearCase的客户在部署和从Rational ClearCase中分段进阶代码方面需要获得帮助的要求。

这篇文章阐明了工具之间可以有清楚利索的合作的事实。文章还强调，在采用适当过程的情况下，我们可以依照Rational ClearCase的一个相同基线提供部署于多个主机上的软件之间的可跟踪性。这些产品是两个完全不同的实体，但是对需要ClearCase环境下的部署方案的顾客来说，它们可以作为一个解决方案共同工作。

对使用以下的演示来说，推荐的软件版本是：ClearCase v2003.06.00，以及Tivoli软件发布4.0。Tivoli软件发布版本4.0捆绑了Tivoli Configuration Manager版本4.2.1。Tivoli Configuration Manager 是一套部署和管理已分段进阶和已部署的软件目录的工具。要获得软件在Tivoli Configuration Manager套装中的发布能力，还需要安装软件许可和发布组件。

Tivoli Configuration Manager

Tivoli Configuration Manager 在多平台环境下控制软件发布并评估管理目录。你可以使用软件发布组件在你的网络内部远程安装，配置和更新软件，而无需手动在大量系统上更新软件。你可以：

在多平台网络中发布客户/服务器应用程序，以及台式机，笔记本及其它一般装置用应用程序
把已有软件更新到新版本
同步分布式系统中的软件

使用Tivoli Configuration Manager 中的软件发布组件，我们可以拉近分段进阶代码库和目标系统之间的距离。这样一个性能良好的解决方案轻易取代了Rational用户自己开发的部署ClearCase下的代码或二进制数的解决方案。

回页首

UCM过程

UCM过程中影响部署活动的主要是构建和部署模式；UCM过程的开发模式对部署来说影响很小。

开发模式

图1：UCM开发模式

在开发环境下开发者将使用UCM提供的标准并行开发范例或顺序开发模型。在该环境下最关键的是理解UCM中哪个流将接受来自多个开发者的变更，并将变更集成起来。这是非常重要的，因为它提供了只部署发生修改的子集（如，用于单元测试），而无需部署整个应用程序的能力。这种能力的产生基于这样一个事实：当使用并行开发时，可以设置多个集成点，而且它们可以有能和系统基线同时分别跟踪和部署的子系统基线。和开发的顺序模型相比，使用并行开发模型在开发过程中有更多灵活性。在顺序模型中，哪个流完成接受和集成变更的工作实际上是既定的。这使得整个基线只能在一个常规基础上进行部署。顺序模型在小型项目中表现良好，但是无法扩展到企业环境中。Tivoli很少介入这个空间。部署活动主要针对的是需要部署的稳定构建。

构建和部署

图2：构建和部署模式

这一阶段开始于发布团队已经对活动清单和基线进行了统一之后。一旦基线活动完成，构建过程就开始了。在多数典型的部署模式中，部署的工件是*.class/*.jar/*.war/*.ear文件或其他派生出的对象（如，二进制代码）。在一些案例中，部署的工件还可以是源代码。认为所有资源文件都是符合基线的。一旦构建完成且基线达到了它的实践等级，衍生出的二进制代码可以包装到一个Tivoli发布包中。

UCM确实在质量的层面上支持实践，于是在UCM的上下文中工件的提升是可以发生的。在一些情况下，特定的组织有他们自己的代码部署客户实践模型。这样一个过程也可以被采用。在目前的环境下我们认为一个UCM实践模型应在Tivoli包创建前就位。根据模式的不同，基线可以由单个或多个组件组成。

理想地，二进制代码可以从构建视图中获得，该视图中产生的对象将一直作为视图的私有对象。二进制文件不会被统一到VOB。根据创建的Tivoli包的类型，视图可以保留也可以删除。

封闭包

一个Tivoli发布包可以是封闭的或开放的。一个封闭包从源主机复制了所有文件并把内容放在一个中心发布服务器上。如果封闭包将被用于常规操作，那么就不需要分段进阶VOB了，因为Tivoli软件发布会管理自己的分段进阶环境，这使得你能够处理多个保存的包之间的差异。部署策略是按照ClearCase的基线来命名软件包。在UCM中这样做将支持部署的可跟踪性，因为发布团队可以根据UCM中同名的基线来跟踪软件包。这样一种特性对注重安全性的公司来说是至关重要的。

包被保存在发布服务器上。Tivoli Configuration Manager 提供了一个目录管理系统来管理部署的日志。Tivoli Configuration Manager 还同时管理它自己的包的版本。当一个同名的新包被创建时它会添加后缀作为版本识别。

动态/开放包

Tivoli支持的另一种包是动态包，它只包含到数据源的指针。例如，如果一个动态包从一个参照特定的基线X的视图中得到它的内容；那么一旦视图由于引进了基线Y（即，重置）中的工件而被更新，如果不创建一个新包的话，动态包将获得它的目录中文件变化了的内容并按要求部署这些文件。为了使集成有意义，实践者必须理解Tivoli包对视图的引用使用的是不变的代码。如果我们建立封闭包这并不是一个问题，但是当我们使用动态包时，删除部署视图将使包出错。

回页首

设置Tivoli

Tivoli的部署模式

图3：Tivoli部署示例

图3描绘了使用Tivoli进行部署的一个典型模式。与典型的Tivoli部署模式相比，唯一的增加是ClearCase的介入。由于ClearCase版本控制系统具备文件系统的能力，Tivoli软件发布会把不同版本的工件看作标准文件系统的一部分。

Tivoli管理基础服务可被用来捕获文件并将其部署到目标环境中。一组共享一个或多个规则组或政策组的资源被定义到一个政策区域中。这个政策区域检测到网络拓扑并定义所有主机和它们的配置详细信息，以及包含软件包的部署文档。在这一模式中，ClearCase代码库和目标服务器是在同一政策区域中被定义的，如果包是封闭的，那么这样做就不是必要的了。

部署工作流

在图3描述的环境中，ClearCase视图显示的是一个包含了需要使用Tivoli软件发布进行部署的基线的只读UCM流。与上述部署模式相关的角色包括发布经理，构建专家，以及部署专家。

构建专家在UCM环境下完成构建。基于构建结果，构建专家继续创建基线并设置一个实践等级。一旦获得了适当的实践等级，这个活动就完成了。可以理解地，这一“新”的基线将被作为从部署到测试主机的一条候选基线。

接着，发布经理按照新的基线重置他/她的只读流，并将其部署到测试目标主机上。文件可以是源文件（即，c，c++，或java文件），二进制代码（*.war, *.ear, *.jar, *.class或*.o文件）或其他任何文件系统的对象。一旦发布经理满意地认为基线确实是部署的候选基线之一了，该基线适当的实践等级也就被设置好了。

发布经理在他/她的工作站或源主机上能够访问Tivoli软件包编辑器。发布经理将继续用相关文件来创建用于部署的软件包。当这一步骤完成后，部署专家团队就可以用Tivoli来确定包的来源并将工件部署到相关的目标上了。

软件发布环境

软件包

软件发布利用了一种称为软件包的简化单一内容包装格式。创建软件包的所有技术都基于这个单一文件格式。一个软件包包含了一组要在工作站上进行的活动。当你建立了一个软件包并将其规到软件发布服务器的目录中后，你就可以使用变更管理操作来管理包活动的执行了。变更管理操作是Tivoli软件发布软件内置的。

在软件发布安装好后，你把软件包作为一个文档类型添加到Tivoli环境中，这样发布活动就开始了。然后你可以在Tivoli管理框架下管理软件包。软件包被导入Tivoli环境并与文档关联起来。软件包文档包含了数据的引用，以及关于数据是如何发布的指令。所有对数据的引用在发布时被解决。

源主机

源主机是存储软件包块的系统，也是软件包中引用资源的位置，以及软件包定义文件存储的地方。任何在你的Tivoli环境下的UNIX, Linux, OS/2, Windows NT, Windows 2000和Windows XP Professional操作系统在Tivoli管理框架和软件发布安装之后都可以作为源主机。在生产环境下，Tivoli框架服务器将与ClearCase VOB服务器分离。

发布一个软件包文档的作用与其他Tivoli文档是不同的：在终点要进行操作，而且资源被发布了。例如，当你发布一个软件包文档，你执行了从源主机向目标机添加文件和目录，从目标机中删除文件和目录，检查目标机的硬盘空间，以及添加Windows注册表项之类的操作。

发布目标（终点）

终点是指一台装有Tivoli管理框架终点代理的计算机，并且是软件发布的一个可能目标机。每个终点被分配到一个终点网关，它提供了一组终点到其他Tivoli环境的通讯装置。网关包括了多路选择发布（MDist2）功能，这使得它能够作为一个驱动多个终点的发布扇出点。服务器资产源——ClearCase视图服务器也配有Tivoli发布网关组件并安装了软件包编辑器。这是动态和封闭包所要求的。原因是Tivoli区域必须能够同包括主机和Tivoli服务器在内的所有用户通讯；前者使文件可见，后者是区域建立的地方。

软件包编辑器

软件包编辑器是一个基于Java的图形界面，用于在Tivoli管理的环境下创建和用户化软件包。软件包在ClearCase主机上建立，该主机上有确定版本的文件对Tivoli是可见的——在本例中，文件就是指ClearCase构建视图。发布主机是指待部署的工件通过ClearCase视图对Tivoli Configuration Manager 可见的系统。在多数情况下发布主机是服务器/工作站，在这些系统中发布经理会管理软件的发布，而且有一个ClearCase视图在系统中运行。

图4：包编辑器

在源主机上建立软件包时，确保添加文件和目录到包的时候，到源位置的路径定义应使用扩展路径名完成，即

/view/deploy_view_ucm/vob/staging_vob (UNIX)
M:\deploy_view_nt_ucm\staging_vob (Win2k/XP/2003)

包建立以后将会在发布主机上被存为*.sp，*.spd， *.spb文件，这就是将被导入到Tivoli管理框架服务器的文件，该服务器将是发布的源主机（可以是ClearCase视图存在的相同服务器，也可以是另一台分离的服务器）。这些包的名字应与部署的UCM基线的名字匹配。

下面是包文件格式的细节：

软件包定义文件(*.spd)
软件包定义文件是软件包的文本版本。一个.spd文件只包含对包中的对象的描述，也就是，一个在目标系统中执行的操作序列而不是实际对象或资源本身。它包括了一个小节的序列，每个小节描述了一个将要被执行的操作。你可以用文本编辑器来修改.spd文件，对小节进行操作，然后在软件包编辑器中重新打开文件并以另一种格式保存它。例如，Microsoft Office 2000 的.spd文件非常长。在软件包文件格式中它被大幅度压缩了。这种格式中的软件包不可构建。不可构建格式是指来自源主机的实际代码并不存在于包中。这种情况只可能发生在包是在软件包编辑器中构建的情况下。
软件包文件(.sp)
保存为该种格式的软件包是一个.spd文件的压缩格式。它只包含对将要在目标系统中运行的操作的描述，而不包括执行这些操作需要的文件和资源。文件和资源存在于源主机中。由于这种格式的软件包只是对软件包的一个描述，它也处于不可构建格式。
软件包块文件(*.spb)
一个软件包块捆绑了所有执行软件包中包含的操作需要的资源，采用的是标准压缩格式。在发布时，资源无须从源主机获得；它们已经被包含在软件包块中了。尽管如此，软件包块必须建立在源主机上。当软件包块被发布到一个终点时，它没有被保存在终点中，而是在目标目录下被解压缩。通过立即解压缩文件，在终点处就不需要为.spb文件准备额外的硬盘空间。一个包含了所有资源的软件包是可以构建的。软件包块最大可达2GB。

软件发布

一旦软件包在管理节点上被创建，Tivoli管理框架服务器（也称为Tivoli管理区域服务器/TMR）将启动发布过程。软件发布过程还可以在Tivoli中用软件发布的命令行界面进行。如前文所述，软件发布发生在Tivoli的定义区域中。在设计一个区域的政策时，还应考虑到部署的安全需求。TMR的界面是Tivoli桌面——如图5所示。

图5：Tivoli桌面

使用Tivoli桌面，Tivoli发布政策区域被建立起来，如前文所述，并且所有目标和发布政策也被建立了。在图6所示的例子中，区域叫做BNS_DEMO区域。

图6：政策区域编辑器

进入政策区域编辑器后，我们启动文档管理器应用程序。使用文档管理器可以创建软件发布文档，并且软件包被从源主机导入进来。导入完成后，包将会被显示，如图7所示。

图 7:文档管理器

当包被导入后，用户可以在多个被列为被发布软件的订阅者的服务器列表中进行添加和删除的操作。在图7中有两种包：一个封闭包和一个开放/动态包。当你建立了一个封闭包时，工件被复制到包中。一旦建立起来，这个包实际上可以不访问ClearCase而被直接部署。另一种包是开放的。这在部署的角度上提供了一些灵活性。开放包不是把所有工件复制到包中，而是包含了指向工件的指针。因此，每当视图的内容发生变更（即，流被重置），相同的包将被复用。它依赖于一个活数据源（即，视图上下文必须相同）。在注重安全性的公司中，这种实践是不被推荐的，默认的方法是为部署创建封闭包。

回页首

小结

ClearCase的文件系统能力使得ClearCase与Tivoli的集成得以存在。在多数情况下，这两种工具间的集成存在于一个适当定义的部署过程中。该过程可以通过脚本实现自动化，因为Rational和Tivoli方案都支持命令行操作。在基线达到一个特定的晋升级别后，一个包的自动化创建就已经在一些客户的帐户中完成了。

以下强调一些该解决方案的部署的关键点：