你想過將ClearCase由base方式轉(zhuǎn)移到UCM方式嗎？你的base配置支持你的組織當前的使用模型嗎？你可能想考慮何時決定轉(zhuǎn)移到UCM方式，這里有來自Christian Buckley和Darren Pulsipher的一些想法。
什么是統(tǒng)一變更管理(UCM)，以及它如何應(yīng)用于IBM? Rational ClearCase?

UCM被發(fā)展出來，使得人們從一個有效的使用模型開始使用ClearCase變得更容易了。這是由于"base" ClearCase配置非常靈活，以至于很多組織發(fā)現(xiàn)使用這個軟件比較困難。為了讓ClearCase對于他們的特殊需求更加有用，他們編寫了自己的腳本和過程。UCM在確定ClearCase使用模型的大多數(shù)公共元素上進行了努力，并創(chuàng)建了使應(yīng)用軟件更加有效的對象和方法。

如果你現(xiàn)在正在運行base ClearCase方式，你可能在某些點上考慮升級至UCM。但是從什么地方開始呢？涉及哪些內(nèi)容呢？區(qū)別在什么地方？在考慮從你當前的ClearCase系統(tǒng)遷移到UCM系統(tǒng)之前，你應(yīng)該首先理解你當前的使用模型－－以及你的組織自從安裝以來如何使用Basic ClearCase對象。這個變化的過程非常類似于第一次遷移到ClearCase系統(tǒng)的過程。對于任何新的項目，你需要弄明白在你可以向前走時你處于什么位置。

首先，你應(yīng)該回顧一下當前使用的基本ClearCase對象。通過回顧當前的對象，你將能夠了解你的基礎(chǔ)裝置和UCM方式之間的區(qū)別，更好地理解新的UCM對象帶給你的ClearCase系統(tǒng)的新功能。進行此變更的大多數(shù)組織發(fā)現(xiàn)，他們已經(jīng)編寫了許多自己的腳本來執(zhí)行由一些UCM對象包含的功能。象這樣的一些情況，采用UCM對象會很好。這會使你受益，因為此時ClerCase與你的定制開發(fā)有相同的功能，在系統(tǒng)里你會有更少的必須支持的腳本，使得你可以花更多的時間關(guān)注實際的工作。

基本的ClearCase對象
如果你已經(jīng)完成了一個配置管理(CM)計劃，同樣可以做。如果你還沒有一個計劃，請參見IBM Rational Unified Process 方法論選擇一個合適的模板。一個好的配置管理 (CM)計劃應(yīng)該包括非常概括的工作流程條款，和特定的ClearCase規(guī)劃。如果你已經(jīng)有了自己系統(tǒng)詳細的規(guī)劃，將會發(fā)現(xiàn)UCM的變化將會相當直接。至少你將會容易地能夠看到無論是否是UCM對于你的實施都是一個很好的適合。那是你希望有一個對于已有對象和你當前的對象的清除的理解－－僅僅因為UCM是可用的，不必要地意義你將會使用它。

UCM主要是對你已經(jīng)一直在使用的base ClearCase 對象增加了額外的對象和工作流。因此，在你著手這些變更前，首先看一下關(guān)于當前使用的ClearCase對象的一些問題：

VOB（版本對象庫）
版本對象庫（VOB）在UCM中如同在base ClearCase使用模型中一樣重要。你有可能在你當前的系統(tǒng)里繼續(xù)使用相同的VOB結(jié)構(gòu)。當你可能改變少量東西使其在UCM中更有效時，你可能希望什么也不做。當然，你將會需要回答一些有關(guān)你的VOB結(jié)構(gòu)的基本問題，這些問題的大多數(shù)可能已經(jīng)在你的配置管理計劃里進行了回答：

你的VOBs是如何計劃的？
你有admin VOBs嗎？
VOBs之間的關(guān)系是怎樣的？
在VOBs里包含哪些種類信息，以及它們的目錄是如何組織的？
視圖（View）
UCM使用視圖做一些有趣的事情。他們通常較之于基礎(chǔ)ClearCase方式執(zhí)行有更長的持續(xù)時間�；卮痍P(guān)于視圖如何創(chuàng)建和刪除是很重要的。另外，配置規(guī)格（config specs）自動地在UCM里產(chǎn)生，并且它們可能不是你所希望的。重要的是你也可以描述配置規(guī)格，因而理解從原有舊系統(tǒng)到新系統(tǒng)的映射。問問你自己：

誰能創(chuàng)建視圖？
視圖創(chuàng)建的頻率是如何的？
視圖創(chuàng)建是自動地還是手動地？
視圖保留多長時間？
什么時候刪除視圖？
配置規(guī)格是自動創(chuàng)建的嗎？
配置規(guī)格是共享的嗎？
標簽（Label）
標簽有太多種不同的使用方法，可以使你變得頭暈。列出關(guān)于標簽的所有可能問題是不可能的，但是如果你是負責任地并構(gòu)建了一個表，這個表包含了在你的系統(tǒng)里的每種標簽類型的信息，那你是處于正確的道路上。在UCM里使用標簽會有助于UCM使用模型。理解下面的問題總會是好的：

標簽如何使用？
什么時候使用標簽？（構(gòu)造，合并，工作流控制）
你的標簽命名方案是什么？
當標簽不再被需要時，如何廢棄和刪除？
分支（Branch）
如果你正在使用base ClearCase而沒有使用分支，那么你可能還是忽略下面的問題比較好，因為實質(zhì)上你還沒有一個base ClearCase的使用模型。如果是這種情況，你可以直接轉(zhuǎn)換到UCM模型，而不用從你的當前模型進行映射。實際上，無論你當前有什么都必須拋棄掉。

如果在你的模型里有分支，那么你有許多工作要做。UCM分支模型使用流的概念，我們稍后會討論。有可能，你的分支模型將會徹底被拋棄。然而，另一方面，你的使用模型可能仍然是可用的。確保你花時間來理解下面的問題：

什么時候創(chuàng)建一個分支類型？
你的命名約定是什么？
什么時候元素移動到分支？
你的分支策略是什么？
有多少人在同一個分支上工作？
你有一個集成分支嗎？
你在“main”分支上做什么？
你要讓你的分支過時效嗎？
什么時候分支被棄用和刪除？
合并（Merging）
與你的分支一樣，你需要花一些時間在本節(jié)里理解關(guān)于合并的問題。UCM有集成點和新的命令來處理從一個分支到另一個分支的代碼合并，這需要通過稱為提交和變基的兩個概念來完成。理解為什么合并以及何時進行合并是非常重要的。問問你自己：

什么時候進行代碼合并？是由一個事件引起觸發(fā)？還是由時間引起觸發(fā)？
代碼是自動合并還是手動合并？
誰對代碼合并負責？
允許從集成分支合并到開發(fā)分支嗎？
從一個開發(fā)分支合并到一個集成分支的頻率是怎樣的？
觸發(fā)器（Trigger）
在大多數(shù)的base ClearCase系統(tǒng)中，觸發(fā)器是非常重要的，因為他們有助于工作流程和過程控制。UCM有一些方針，包括了ClearCase觸發(fā)器的使用。確保你的配置管理計劃描述了你的觸發(fā)器和使用它們的VOB。理解這些問題是重要的：

你使用的觸發(fā)器是什么，為什么要使用它們？
哪些VOB使用的哪些觸發(fā)器？
　

UCM中的基本對象
Base ClearCase提出了一些很抽象的概念，例如分支，標簽，超鏈接，元素，視圖和版本對象庫，UCM作出了更高級別的抽象，我們每天用于進行開發(fā)，集成和提交產(chǎn)品。這些更高層的概念是：

項目（Project）
流（Stream）
活動（Activitie）
基線（Baseline）
構(gòu)件（Component）
如果你已經(jīng)使用base ClearCase 有一段時間了，你會很快發(fā)現(xiàn)這些概念已經(jīng)存在你的系統(tǒng)里了，要么是在文檔中，要么在腳本中。可以把它認為是你的才華的一個證實，軟件現(xiàn)在提供了你曾經(jīng)創(chuàng)建腳本去做的所有事情－－現(xiàn)在你可以繼續(xù)輕松下來，使用這些可利用的東西。

項目（Project）
項目用于為一組人在一個單一的項目上提供工作。它可以是一個產(chǎn)品的發(fā)布，一個完整項目的子系統(tǒng)，或者是集成一些產(chǎn)品形成一個套間。項目包含了一個集成流和零個和多個開發(fā)流。這是項目必須的開始計劃。當開始創(chuàng)建項目前，盡管你需要和市場人員、軟件開發(fā)團隊、質(zhì)量保證人員坐下來討論，同時技術(shù)方面的作者開始確定你希望如何一起工作。