使用Tivoli軟件進行Rational ClearCase UCM的發布

IBM Tivoli配置管理器是對IBM Rational ClearCase代碼分段和代碼部署提供了一個高效的解決方案。Tivoli 和 ClearCase無縫的連接用于提供發布能力，以及跟蹤從分段的庫到目標系統的開發過程。
概述

介紹
用戶面臨的一個典型問題是在ClearCase下缺乏部署能力。?。由于能夠從開發跟蹤軟件資產（雙向的），測試和部署也是某些客戶面臨的一個巨大的問題。為了管理和控制開發過程，他們必須利用其它的產品或開發自己的產品。Tivoli軟件提供了滿足此種需要的能力?？焖俨渴疬B接著貫穿整個從開發到測試到產品的生命周期所提供的軟件資產管理。

自從IBM收購Rational之后，Tivoli和Rational在如何完成彼此的解決方案上進行了合作。Tivoli的配置管理軟件發布解決方案響應了大多數ClearCase用戶要求的從Rational ClearCase中部署和進階代碼的協助。

本文列舉了工具間的相互合作。本文也強調，在適當的時機使用合適的程序，我們可以提供在多主機軟件開發到一個確定的Rational ClearCase基線的可跟蹤性。這些產品有兩個明顯的實體，但是可以為用戶作為一個解決方案工作在一起，需要在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環境里完成構造?；跇嬙斓慕Y果，構造專家創建基線和提升基線集。一旦達到適當的提升級別，活動就完成了。這可以理解為這個“新”基線是作為開發的候選基線用于測試的主機。

發布經理隨后變基他/她的只讀流到新的基線并用于測試的目標主機上。文件會是源文件（也就是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服務器和管理節點網關，以及終端（目標）。一個組織可以有多個域。

參考
Tivoli 軟件發布用戶指南來自
http://publib.boulder.ibm.com/tividd/td/ConfigurationManager4.2.1.html

Mary Lai (Software IT Architect) IBM Canada

Jennie A Brown (Jennie) IT Specialist, Rational Software, IBM USA

Malcolm D Thomas (Dudley), IT Services Specialist, Rational Software, IBM USA

原文轉自：http://www.kjueaiud.com