Darren Pulsipher （darrenp@cadence.com） , 配置管理架構師, Cadence Design Systems
你想過將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方式執行有更長的持續時間�；卮痍P于視圖如何創建和刪除是很重要的。另外，配置規格（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 有一段時間了，你會很快發現這些概念已經存在你的系統里了，要么是在文檔中，要么在腳本中�？梢园阉J為是你的才華的一個證實，軟件現在提供了你曾經創建腳本去做的所有事情－－現在你可以繼續輕松下來，使用這些可利用的東西。
項目（Project）
項目用于為一組人在一個單一的項目上提供工作。它可以是一個產品的發布，一個完整項目的子系統，或者是集成一些產品形成一個套間。項目包含了一個集成流和零個和多個開發流。這是項目必須的開始計劃。當開始創建項目前，盡管你需要和市場人員、軟件開發團隊、質量保證人員坐下來討論，同時技術方面的作者開始確定你希望如何一起工作。
有關項目的ClearCase 命令包括：mkproject, lsproject, chproject, 和rmproject。
流（Stream）
流可以比喻成開發的分支。流基本上是由元素的特定版本組成。普通分支和流主要的區別是在流里保存了附件的信息。比如，流里包含了基線，和一組活動。它也可以包含和其它流的關系，比如父流�；�，加上活動集，決定流里包括元素的哪些版本。
圖1：流的例子
在圖1里，有兩個活動－－活動1和活動2－－已經添加到了流里�；�由那些在圖里顯示為粗體線條的元素版本表示。兩個活動包含表示為不同的模式的元素版本。
流有兩種基本的類型：集成流和開發流。對項目有一個且只有一個集成流 。在非常簡單的項目里，開發者可以在集成流里做變更，工作在流里的每個項目成員只要一有檢入，就會看到所有其它的變更。更復雜的項目可能有一個和更多級別的開發流，它們始于集成流的不同基線配置。在此情況下，開發者在其唯一的開發流上進行“個人”工作，并且項目成員不會立即看到彼此的工作。一旦開發者完成了他們自己在開發流上的工作，并準備共享給其余的項目成員時，開發流的內容被“提交”到集成流上。想像集成流是把來自開發流的所有變更集合在一起。
圖2：集成流的例子
有關流的ClearCase命令包括： mkstream, lsstream, chstream, 和rmstream。
基線（Baseline）
基線代表了用于開始一個流和變基一個流的元素版本。一種查看基線的簡單方法是把它們和標簽進行比較，困難在于附加信息（包括關系）保存在基線里�；�是很多活動的起點，比如創建流，變基流，等等。
有關基線的ClearCase命令包括：mkbl, lsbl, chbl, rmbl, diffbl, setplevel, 和cleardiffbl。
活動（Activitie）
在ClearCase UCM項目里對任何元素的所有的變更必須關聯到一個活動。一個活動是你的團隊成員工作的基本單元。它有以下這些構件：
一個標題（ID）
一個創建者
一個變更集（變更元素的集合）
一個相應的流
如果你正在使用IBM Rational ClearQuest，一個活動通常聯系到一個缺陷或一條增強請求。
有關活動的ClearCase命令包括：mkactivity, lsactivity, chactivity, 和rmactivity。
構件（Component）
構件允許你組建一組相關的目錄和文件元素在一起，并且把它們和UCM項目進行綁定。一個構件被開發、集成，并且其所有的部分是一起發布的。所有的項目必須有一個和多個構件，并且在項目間可以共享構件。然而，一個構件不能跨越多個版本對象庫（VOB），最大的構件大小就是它的版本對象庫（VOB）。關于構件的其它內容包括：
元素不能從一個構件移動到另一個構件。
一個元素只能存在一個構件里。
一旦創建了一個構件，你不能重新組織它到子構件里。
預先計劃構件是非常重要的。一個策略是：將要共享給其它項目的所有元素置于同一個構件中，或放到構件組中。
有關構件的ClearCase命令包括：mkcomp, lscomp, 和rmcomp。
文件夾（Folder）
一個文件夾是一個項目或多個項目包含信息的容器。文件夾可以包含其他的文件夾，以及任意數量的項目。你可能在你的VOB中一直在使用目錄作為base ClearCase中的某些對象種類的一個文件夾�，F在文件夾是第一個類對象，作為替代，你可以使用它們。
有關文件夾的ClearCase命令包括：mkfolder, lsfolder, rmfolder 和chfolder。
有用的UCM命令
理解UCM對象是將你的當前過程映射到UCM的第一步，但是為了有助于你的規劃，還有一些你應當很好了解的常用命令。這些是基本的命令，可能是開發者經常使用的，理解什么時候使用這些命令是非常重要的。
工作在活動上
在檢入或檢出文件前，開發者需要設置一個活動到當前的視圖�；顒訉⒏櫾谝晥D里發生的變化。所有的變更保存在一個變更集里。當提交活動時，變更集關聯到這些提交到集成流里的活動，因此團隊里的每個人能看到這些變更。
提交變更
一旦在一個活動上結束工作，你可以提交你的變更到默認的集成流（父流），或者提交到任何其它的你選擇的流。流可以接受或拒絕變更，這取決于在團隊里建立的方針。提交活動的命令是：
cleartool deliver －－ 將元素的變更從一個源流提交到目標流。提交的狀態也可以從此命令得到。
當提交開始時，它創建一個特殊的活動提交變更到集成流�；顒拥膭摻ㄓ兄诠芾砣魏慰赡艿暮喜_突和解決措施。提交可以分兩步完成，或者是在一個單獨步驟中完成。第一步是執行變更元素的合并。第二步確定變更并標識活動的完成。你可以通過使用complete標記來強制一步提交完成。
變基工作空間
你可能會階段性地從集成流變基你的流。記�。愕拈_發流通常會等待很長時間。你會階段性地需要從你的團隊成員的活動上得到更新�；旧�，在ClearCase變基命令只做如下工作：提供（并然后變更）其它團隊成員已經提交到一個集成流上的活動。
cleartool rebase -- 變更流的配置
變基流時是一個多步驟的過程，很象提交活動。你可以從集成流集成代碼到開發流，這包括移動標簽并解決合并沖突。如同提交命令一樣，-complete可以用于將自動創建的活動標記為已完成（換句話說，強制進行一步變基）。
作為一個配置經理，你最好提供推薦基線，來讓開發者能變基他們的開發流。例如，一個穩定的構造可以放到推薦的基線列表上，使開發者能夠看到他們正在從一個在給定時間上的代碼開始工作。
將兩個世界連在一起
由于使用 base ClearCase，很多UCM模型的概念對于你已經做的可能不是很困難�，F在主要規劃的是什么是UCM要做的。接下來你能可以檢查一下從整個UCM中得到的不同可用模型間的區別。這不是你能在兩個小時內做到的－－正如我們所概述的，你會需要花時間來構建一個完整的配置管理計劃。你也需要徹底地詳細說明你目前在使用什么，以及你想使用UCM做什么。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
