使用Tivoli软件进行Rational ClearCase UCM的发布

　　概述

　　介绍

　　用户面临的一个典型问题是在ClearCase下缺乏部署能力。。由于能够从开发跟踪软件资产（双向的），测试和部署也是某些客户面临的一个巨大的问题。为了管理和控制开发过程，他们必须利用其它的产品或开发自己的产品。Tivoli软件提供了满足此种需要的能力。快速部署连接着贯穿整个从开发到测试到产品的生命周期所提供的软件资产管理。

　　自从IBM收购Rational之后，Tivoli和Rational在如何完成彼此的解决方案上进行了合作。Tivoli的配置管理软件发布解决方案响应了大多数ClearCase用户要求的从RationalClearCase中部署和进阶代码的协助。

　　本文列举了工具间的相互合作。本文也强调，在适当的时机使用合适的程序，我们可以提供在多主机软件开发到一个确定的RationalClearCase基线的可跟踪性。这些产品有两个明显的实体，但是可以为用户作为一个解决方案工作在一起，需要在ClearCase环境下开发一个解决方案。

　　对于使用这个演示的推荐版本是解决方案提供的最新版本：ClearCase v2003.06.00，和Tivoli软件发布4.0版。Tivoli软件发布4.0版本和Tivoli配置管理4.2.1版本绑定。Tivoli配置管理是一套部署并管理已进阶和部署软件的详细目录的Tivoli工具。许可证和软件分布组件为了软件分布能力需要进行安装，以工作在Tivoli 配置管理器套件中。

　　Tivoli 配置管理器

　　Tivoli配置管理器控制软件分配和资产管理。使用软件分布构件，你可以安装、配置和更新远程软件，避免在众多的系统里手动更新软件。你可以：

　　分布式客户/服务器应用程序，桌面应用程序，便携式电脑和跨多个平台网络普通设备。

　　使用新的版本更新现有软件

　　在分布式系统里同步软件

　　在Tivoli配置管理器里使用软件分布构件，我们能在阶段代码和目标系统之间减少缝隙。

　　UCM过程

　　UCM过程影响开发活动主要是在构造和部署场景上；UCM的开发场景对开发活动影响很小。

　　开发场景

图1:UCM开发构想

　　在开发环境下，开发者使用UCM提供的标准的并行开发规范（或者连续开发模型）。在这种环境下什么是至关紧要的，就是了解UCM里的哪一种流将会接收来自不同开发者的变更，并集成这些变更。这点是很重要的，因为它只允许修改子集（例如单元测试），或者是整个的软件。这拒绝于以下事实，当使用并行开发时，可以建立多个集成的点以及子系统的基线，可以跟踪并单独开发这些系统的基线版本。使用并行开发模型比连续开发在开发上有更多的灵活性。在连续开发模型里，可以含蓄地理解成，把流假设成此角色。在整个基线里，是在有规律的基础上进行开发。连续开发模型可以较好地应用于小的项目。在这种情况下，包括Tivoli空间都是很小的。开发活动主要集中在需要部署的稳定的构造上。

　　构造与部署

图2：构造和部署场景

　　在这个阶段的开始，是当发布团队整理好了对于基线的活动列表。一旦基线活动发生了，构造的过程就开始了。在大多数典型的部署场景中，部署的工件包括：*.class/*.jar/*.war/*.ear文件和其他对象（比如二进制文件）。在一些情况下，部署的工件也包括源代码。假设所有的源程序都被检入到基线。一旦构造完成，基线通过其晋升级别，派生的二进制文件就可以打包到Tivoli发布包里了。

　　UCM支持从一个质量级别晋升的概念，因此，工件的提升发生在UCM的环境里。在某些情况下，特定的组织有他们自己为代码开发定制的模型。这样的过程也是可以支持的。在当前的场景里，假设在创建Tivoli包之前，UCM提升模型是合适的。依据这样的想法，基线既可以是复合的，也可以是单一构件的基线。

　　二进制文件从一个构建视图理想化地被开发，视图中产生对象并保持对象的私有性。二进制文件将不能检入到版本对象库（VOB）。依赖于创建Tivoli包的类型，视图可以存在或被删除。

　　关闭的包

　　一个Tivoli分配包可以关闭或打开。一个关闭的包从源主机复制所有的文件，将这些内容放置到一个中心分配服务器上。如果关闭的包将要用于一个有规律的基线，那么阶段性的版本对象库可能是不需要的，因为Tivoli软件分配管理它自己的阶段环境，这允许你在几个保存的包之间有不同的执行。开发策略是在有了ClearCase基线后给软件包命名。UCM支持基线的可跟踪性，允许发布团队跟踪这个包用来在UCM里确认基线。这样的特征对重视安全的企业非常重要。

　　包是保存在分布服务器上的。Tivoli配置管理器提供了一个控制系统来管理开发日志。Tivoli配置管理器管理它自己的包的版本。当一个新的包用了一个相同的名称来创建，它会增加一个后缀进行版本识别。

　　动态的或打开的包

　　Tivoli支持的其他类型的包是动态包，只包括点到数据来源。例如， 如果动态包从一个特殊的试图查看基线X；一旦视图从基线Y（也就是变基）更新引入工件，没有创建新的包，动态包挑出文件内容的变更，并按要求配置文件。为了集成工作，工作人员必须了解Tivoli包有硬代码更新到视图。如果我们创建关闭包，这不是问题，但是当使用动态包时，去除开发试图将会使包无效。

　　安装Tivoli

　　Tivoli的部署场景

图3：简单的Tivoli部署

　　一个典型的Tivoli部署场景可用图3描述。对于典型的Tivoli部署场景唯一增加的是涉及到了ClearCase。由于ClearCase版本控制系统有文件系统的能力，Tivoli软件分布将版本化工件视为标准文件系统的一部分。

　　Tivoli的基础组织服务，可以用于捕获文件和配置目标环境。源代码的集合共享一个或更多的共同规则或方针集，定义成方针域。这个方针域捕获网络技术并定义所有的主机和它们的配置细节。在此场景中，ClearCase库和目标服务器都会定义在相同的方针域中，如果包是一个关闭的包，那么这可能不是必须的。

　　部署工作流

　　在图3描绘的环境里，ClearCase视图看上去是一个只读的UCM流，包括了需要开发使用Tivoli软件分配的基线。这个角色包含了发布经理，构造专家，以及部署专家。

　　构造专家在UCM环境里完成构造。基于构造的结果，构造专家创建基线和提升基线集。一旦达到适当的提升级别，活动就完成了。这可以理解为这个“新”基线是作为开发的候选基线用于测试的主机。

　　发布经理随后变基他/她的只读流到新的基线并用于测试的目标主机上。文件会是源文件（也就是c，c++，或者java），二进制文件（*.war, *.ear, *.jar, *.class 或者 *.o）或者任何其它的文件系统对象。

　　发布经理已经访问了Tivoli软件包，编辑了他/她的工作空间或者源程序主机。发布经理将会为使用有关的文件开发创建软件包。一旦此步骤完成，开发团队能够为相关的目标使用Tivoli开发工件。

　　软件分布环境

　　软件包

　　软件分布利用一个简单的单一内容的包的形式，称为软件包。所有的这项技术用于创建的软件包是基于这个单一的文件格式。一个软件包包含了动作的集合，在一个工作空间执行。当你创建了一个软件包后，并在软件发布服务器上编制了目录，你能够使用变更管理操作来管理包的操作如何被执行。变更管理操作与Tivoli软件分配有内在的联系。

　　随着软件分布的建立，为了着手分配活动，增加了一个档案类型，软件包，到Tivoli环境。接下来你能够在Tivoli管理框架里管理软件包。软件包被导入进Tivoli环境，并且关联到档案。软件包档案包含涉及的数据，和关于数据如何被分配的结构。所有的涉及数据的解决在分布时间。

　　源主机

　　源主机是保存软件包的系统。在Tivoli管理框架和软件发布建立后，任何在你的Tivoli环境里的UNIX, Linux, OS/2, Windows NT, Windows 2000, 以及 Windows XP Professional 操作系统可以是一个源主机。在一个生产环境里，Tivoli框架服务器将要从ClearCase 版本对象库服务器里分离出来。

　　分布一个软件包档案的影响不同于其它的Tivoli档案：在终点和资源执行的操作是被分布的。例如，当你分布一个软件包档案，你执行了操作，例如从源主机增加文件和目录到目标，从目标处删除文件和目录，检查目标的磁盘空间，增加Windwos 注册密匙。

　　分布目标（终点）

　　一个终点是安装了Tivoli管理框架的计算机，并且是一个软件发布可能的目标。每个终点被分配到一个终点的网关，提供了所有点到点的通讯。网关包括了多元的分布功能。ClearCase视图服务器分布到很多的点，并且安装了软件包编辑器。这种情景需要动态视图并关闭包。这是由于Tivoli 域必须能够于所有的客户端通讯。

　　软件包编辑器

　　软件包编辑器是基于Java的图形化界面，用于在Tivoli管理环境下创建和自定义软件包。软件包在ClearCase主机上创建，版本化的文件在Tivoli上是可见的－－既然这样，它将会是ClearCase构建视图。在很多情况下，服务器/工作站是用来管理发布的，在它上面会运行ClearCase视图。

图4包编辑器

　　When creating the software package on the source host, make sure that when adding files and directory to the package the path definition to the source location should be done using the view extended path name i.e./////当在源主机上创建软件包时，确保将文件和目录添加到包时。

　　/view/deploy_view_ucm/vob/staging_vob(UNIX)

　　M:\deploy_view_nt_ucm\staging_vob(Win2k/XP/2003)

　　创建包之后，在发布主机上包保存为 *.sp,*.spd, *.spb 文件，这些文件将会导入Tivoli管理框架服务器，这会是用于发布的源主机。这些包的命名会符合UCM的基线命名。

　　在包文件上的详细格式如下：

　　软件包定义文件（*.spd）

　　软件包定义文件是软件包的文本文件版本。一个.spd文件只包含了对象的描述，换句话说，是在目标系统上的连续动作。它包含了节的序列，每一个描述了执行的操作。使用文本编辑器，你可以修改一个.spd文件，然后在软件包编辑器里重新打开这个文件，并用另外的格式保存。比如，这个.spd文件对于Microsoft Office 2000 是很长的。在软件包文件格式里被压缩成非常小的尺寸。这种格式的软件包是非构建格式的。非构建格式规定了从源主机取的真实代码不保存在包里，只发生在如果包被构建在软件包编辑器里的时候。

　　软件包文件（.sp）

　　保存为这种格式的软件包压缩成一个.spd文件。它之包含了一个动作的描述，用来在目标系统上执行。文件和资源保存在源主机上。由于这种格式的软件包之是软件包的一个描述，它不是构建格式。

　　软件包块文件（*.spb）

　　软件包块绑定了所有包含在标准压缩格式的执行操作。在发布的时候，源文件不需要从源主机上收集；它们已经包含在软件包的块里。然而，软件包块必须存在于源主机上。当软件包块发布到一个终端时，并不保存在这个终端，而是在目标目录里解压缩。随着压缩文件的立即解压，不需要额外的磁盘空间保存.spb文件。一个包含了所有它的源文件的软件包就是构建的格式。软件包最大是2 GB。

　　软件发布

图5：桌面

　　使用Tivoli桌面，创建了Tivoli发布策略域，确定了所有的目标和发布策略。正如图6的例子，这个域称为BNS_demo域。

图6：方针域编辑器

　　一旦进入方针域编辑器，就开始档案管理应用。使用档案管理，创建了软件发布的档案，软件包从源主机导入。一旦导入了包，如图7所示。

图7：档案管理器

　　当导入包后，用户可以脱拽包到多个服务器做为发布的软件。在图7里，有两种类型的包：一个关闭的包和一个打开/动态的包。当你创建了一个关闭的包，工件就复制到这个包里。一旦创建，对包的开发可以不实际访问ClearCase。其它的包是一个打开的包。这允许从开发角度有一些灵活。打开的包不是从物理上复制所有的内容到包里。因此，每次视图内容的变更（也就是说流的变基）同样的包可以被复用。这依赖于一个可行的数据来源（即 视图内容必须是相同的）。在有安全意识的公司里，这项实践是不被推荐的，默认的方法是为开发创建一个关闭的包。

　　总结

　　在ClearCase和Tivoli之间存在着集成，是由于ClearCase的文件系统。在很多情况下，两种工件间的集成存在着通过定义一种合适的开发过程。这种过程可以通过脚本自动执行，这是由于Rational和Tivoli的解决方案都有丰富的命令行。当基线达到一个特殊的水平时，自动地在一些用户账号里创建一个包。

　　关于此解决方案部署需要强调的一些关键点如下：

　　使用流策略支持发布的颗粒度。

　　开放包可以用于开发和测试阶段，但是关闭包用于最终的发布产生阶段。

　　当使用开放包时，视图服务器必须对适当的Tivoli组件是可见的。

　　一旦创建了关闭包，不需要访问视图服务器的实际内容。

　　基线和包的名字需要同步以支持可跟踪性。

　　按照一个文档化的持续过程使用这些解决方案，你可以提供发布和可跟踪支持。

　　术语表

　　UCM －－统一变更管理， IBM/Rational的软件开发范例，使用ClearCase和ClearQuest实施。

　　Tivoli 管理节点－－一个在Tivoli管理框架上安装的服务器/工作站。

　　端点－－任何类型的Tivoli 操作最终的收集。

　　方针－－一组应用到管理资源的规则

　　方针域－－一组共享一个或多个公共方针的管理源，模拟管理或组织的网络计算环境的结构。

　　档案－－在一个Tivoli 环境里，关于特殊类型应用的资源信息容器。

　　Tivoli 桌面－－在Tivoli 环境下，桌面是系统管理员管理网络上的计算机环境。

　　Tivoli 管理域－－服务于Tivoli服务器和管理节点网关，以及终端（目标）。一个组织可以有多个域。