你想過將ClearCase由base方式轉移到UCM方式嗎？你的base配置支持你的組織當前的使用模型嗎？你可能想考慮何時決定轉移到UCM方式，這里有來自Christian Buckley和Darren Pulsipher的一些想法。
什么是統一變更管理(UCM)，以及它如何應用于IBM? Rational ClearCase?
UCM被發展出來，使得人們從一個有效的使用模型開始使用ClearCase變得更容易了。這是由于"base" ClearCase配置非常靈活，以至于很多組織發現使用這個軟件比較困難。為了讓ClearCase對于他們的特殊需求更加有用，他們編寫了自己的腳本和過程。UCM在確定ClearCase使用模型的大多數公共元素上進行了努力，并創建了使應用軟件更加有效的對象和方法。
如果你現在正在運行base ClearCase方式，你可能在某些點上考慮升級至UCM。但是從什么地方開始呢？涉及哪些內容呢？區別在什么地方？在考慮從你當前的ClearCase系統遷移到UCM系統之前，你應該首先理解你當前的使用模型－－以及你的組織自從安裝以來如何使用Basic ClearCase對象。這個變化的過程非常類似于第一次遷移到ClearCase系統的過程。對于任何新的項目，你需要弄明白在你可以向前走時你處于什么位置。
首先，你應該回顧一下當前使用的基本ClearCase對象。通過回顧當前的對象，你將能夠了解你的基礎裝置和UCM方式之間的區別，更好地理解新的UCM對象帶給你的ClearCase系統的新功能。進行此變更的大多數組織發現，他們已經編寫了許多自己的腳本來執行由一些UCM對象包含的功能。象這樣的一些情況，采用UCM對象會很好。這會使你受益，因為此時ClerCase與你的定制開發有相同的功能，在系統里你會有更少的必須支持的腳本，使得你可以花更多的時間關注實際的工作。
基本的ClearCase對象
如果你已經完成了一個配置管理(CM)計劃，同樣可以做。如果你還沒有一個計劃，請參見IBM Rational Unified Process 方法論選擇一個合適的模板。一個好的配置管理 (CM)計劃應該包括非常概括的工作流程條款，和特定的ClearCase規劃。如果你已經有了自己系統詳細的規劃，將會發現UCM的變化將會相當直接。至少你將會容易地能夠看到無論是否是UCM對于你的實施都是一個很好的適合。那是你希望有一個對于已有對象和你當前的對象的清除的理解－－僅僅因為UCM是可用的，不必要地意義你將會使用它。
UCM主要是對你已經一直在使用的base ClearCase 對象增加了額外的對象和工作流。因此，在你著手這些變更前，首先看一下關于當前使用的ClearCase對象的一些問題：
VOB（版本對象庫）
版本對象庫（VOB）在UCM中如同在base ClearCase使用模型中一樣重要。你有可能在你當前的系統里繼續使用相同的VOB結構。當你可能改變少量東西使其在UCM中更有效時，你可能希望什么也不做。當然，你將會需要回答一些有關你的VOB結構的基本問題，這些問題的大多數可能已經在你的配置管理計劃里進行了回答：
你的VOBs是如何計劃的？
你有admin VOBs嗎？
VOBs之間的關系是怎樣的？
在VOBs里包含哪些種類信息，以及它們的目錄是如何組織的？
視圖（View）
UCM使用視圖做一些有趣的事情。他們通常較之于基礎ClearCase方式執行有更長的持續時間。回答關于視圖如何創建和刪除是很重要的。另外，配置規格（config specs）自動地在UCM里產生，并且它們可能不是你所希望的。重要的是你也可以描述配置規格，因而理解從原有舊系統到新系統的映射。問問你自己：
誰能創建視圖？
視圖創建的頻率是如何的？
視圖創建是自動地還是手動地？
視圖保留多長時間？
什么時候刪除視圖？
配置規格是自動創建的嗎？
配置規格是共享的嗎？
標簽（Label）
標簽有太多種不同的使用方法，可以使你變得頭暈。列出關于標簽的所有可能問題是不可能的，但是如果你是負責任地并構建了一個表，這個表包含了在你的系統里的每種標簽類型的信息，那你是處于正確的道路上。在UCM里使用標簽會有助于UCM使用模型。理解下面的問題總會是好的：
標簽如何使用？
什么時候使用標簽？（構造，合并，工作流控制）
你的標簽命名方案是什么？
當標簽不再被需要時，如何廢棄和刪除？
分支（Branch）
如果你正在使用base ClearCase而沒有使用分支，那么你可能還是忽略下面的問題比較好，因為實質上你還沒有一個base ClearCase的使用模型。如果是這種情況，你可以直接轉換到UCM模型，而不用從你的當前模型進行映射。實際上，無論你當前有什么都必須拋棄掉。
如果在你的模型里有分支，那么你有許多工作要做。UCM分支模型使用流的概念，我們稍后會討論。有可能，你的分支模型將會徹底被拋棄。然而，另一方面，你的使用模型可能仍然是可用的。確保你花時間來理解下面的問題：
什么時候創建一個分支類型？
你的命名約定是什么？
什么時候元素移動到分支？
你的分支策略是什么？
有多少人在同一個分支上工作？
你有一個集成分支嗎？
你在“main”分支上做什么？
你要讓你的分支過時效嗎？
什么時候分支被棄用和刪除？
合并（Merging）
與你的分支一樣，你需要花一些時間在本節里理解關于合并的問題。UCM有集成點和新的命令來處理從一個分支到另一個分支的代碼合并，這需要通過稱為提交和變基的兩個概念來完成。理解為什么合并以及何時進行合并是非常重要的。問問你自己：
什么時候進行代碼合并？是由一個事件引起觸發？還是由時間引起觸發？
代碼是自動合并還是手動合并？
誰對代碼合并負責？
允許從集成分支合并到開發分支嗎？
從一個開發分支合并到一個集成分支的頻率是怎樣的？
觸發器（Trigger）
在大多數的base ClearCase系統中，觸發器是非常重要的，因為他們有助于工作流程和過程控制。UCM有一些方針，包括了ClearCase觸發器的使用。確保你的配置管理計劃描述了你的觸發器和使用它們的VOB。理解這些問題是重要的：
你使用的觸發器是什么，為什么要使用它們？
哪些VOB使用的哪些觸發器？
UCM中的基本對象
Base ClearCase提出了一些很抽象的概念，例如分支，標簽，超鏈接，元素，視圖和版本對象庫，UCM作出了更高級別的抽象，我們每天用于進行開發，集成和提交產品。這些更高層的概念是：
項目（Project）
流（Stream）
活動（Activitie）
基線（Baseline）
構件（Component）
如果你已經使用base ClearCase 有一段時間了，你會很快發現這些概念已經存在你的系統里了，要么是在文檔中，要么在腳本中。可以把它認為是你的才華的一個證實，軟件現在提供了你曾經創建腳本去做的所有事情－－現在你可以繼續輕松下來，使用這些可利用的東西。
項目（Project）
項目用于為一組人在一個單一的項目上提供工作。它可以是一個產品的發布，一個完整項目的子系統，或者是集成一些產品形成一個套間。項目包含了一個集成流和零個和多個開發流。這是項目必須的開始計劃。當開始創建項目前，盡管你需要和市場人員、軟件開發團隊、質量保證人員坐下來討論，同時技術方面的作者開始確定你希望如何一起工作。
