1 簡介

1.1 目的
本文的目的是介紹某公司在將軟件資產(chǎn)從其他配置管理工具遷移到IBM Rational公司的ClearCase UCM配置管理解決方案的一些經(jīng)驗。

1.2 概念
在使用ClearCase之前，必需理解某些概念：

    Element 納入配置管理的包括版本信息的配置項，包括文件與目錄。
    VOB Version Object Base，存放配置項的庫。
    UCM Unified Changed Management的縮寫，統(tǒng)一變更管理模式
    Activity Activity是ClearCase UCM模式中的一個概念，通過變更集(Change Set)跟蹤完成一項開發(fā)任務(wù)所引起的所有配置項的變更。在UCM模式下所有的Check Out、Check In、Add to Source Control等引起配置項發(fā)生變化的操作必須關(guān)聯(lián)到一個Activity。
    Change Set Change Set記錄了Activity所關(guān)聯(lián)的所有的配置項的版本變更，每個Activity都有一個Change Set。
    Component 可以理解為一些代碼、文檔、Model等按一定的目錄結(jié)構(gòu)組織成的完成某些功能的可以重用的集合。這是UCM所引入的概念，Component與UCM Project相關(guān)聯(lián)，UCM Project所管理的所有的Element必定從屬于一個Component，每個UCM Project至少有一個Component。
    Deliver UCM的概念，是一個從開發(fā)流向UCM Project集成流或其他開發(fā)流提交工作的一個動作。
    Development Stream UCM的概念，可以理解為一個獨立的開發(fā)環(huán)境，包含了在這個開發(fā)流上的Activity與修改的配置項的版本，UCM通過開發(fā)流簡化了并行開發(fā)的配置管理工作。
    Dynamic View Dynamic View是對VOB的一個動態(tài)視圖，VOB的變化會及時反應(yīng)到Dynamic View上，每個Dynamic View都關(guān)聯(lián)到一個Stream上，在Dynamic View上會有一些View的私有文件，這些View私有文件不會被同一個Stream上的其他View所見到。
    Integration Stream UCM的概念，可以理解為項目的主干，每個開發(fā)流都是集成流的一個分支，在開發(fā)流上完成工作后，再提交到主干，項目的Build環(huán)境建議采用集成流
    Project 是ClearCase UCM的一個概念，包含了配置管理所需要的一些配置信息，如果Component、Baseline，Stream等，每個Project都有一個Integration Stream。
    Project VOB(PVOB) 是存儲UCM所需要的一些特殊的信息，如Proejcts，Stream，Activity及Change Sets等，一個PVOB可以包含多個Project的信息， Project的信息必須保存在PVOB中。
    Rebase UCM模式的一個操作，讓當(dāng)前Stream的View的內(nèi)容與Integration Stream推薦基線同步。
    Snapshot view Snapshot View是對VOB的一個靜態(tài)視圖，將相關(guān)的VOB的選定的版本下載到本地保存，需要經(jīng)常進行Update View操作以保證與關(guān)聯(lián)的stream同步。
    Add to Source Control 執(zhí)行將選定的文件或目錄納入ClearCase管理的動作，需要注意的是，如果要在某一目錄下添加文件或目錄，必須先將它所在的目錄先Check out，再在該目錄下執(zhí)行Add to Source Control動作，而后再對當(dāng)前目錄執(zhí)行Check in；如果正確執(zhí)行完成后，該文件與目錄后的類型會變?yōu)镕ile element Version或Directory Version，如果沒有將當(dāng)前目錄Checkout執(zhí)行Add to Source Control，則在執(zhí)行完成后文件的類型還是View-private File或View-private Directory，在這種情況下，該文件或目錄實際上沒有納入配置管理。

2 計劃與準(zhǔn)備

2.1 計劃
配置管理切換大至可以劃分為以下幾個階段：計劃，準(zhǔn)備，配置庫的遷移，正式使用。

配置管理切換計劃的主要內(nèi)容包括進度、資源等。

項目的規(guī)模與所處的階段不同，則配置管理切換所需要的時間也不同。一個20人左右，開發(fā)進度約達到計劃的一半，代碼量達到50K左右的項目，從開始計劃到配置管理完全切換到ClearCase，少需要3-4周時間。如果盲目的追求進度，想在1-2周內(nèi)切換完成，則可能在切換后產(chǎn)生一系列后遺癥，如版本丟失、版本錯誤甚至可能會有部分項目組成員抵制，從而使項目開發(fā)進程中部分工作不能納入配置管理之下。

進度安排建議：根據(jù)項目的情況用5-15個工作日進行準(zhǔn)備，配置庫的遷移需要5個工作日左右的時間，配置管理工程師要用5-10個工作日的跟進以使項目組成員熟悉并不再需要幫助。

任何計劃都有一個前提：資源，不同的資源會導(dǎo)致不同的進度與成本。在配置管理切換中三類資源非常重要：經(jīng)過培訓(xùn)并且有ClearCase經(jīng)驗的配置管理工程師；經(jīng)過培訓(xùn)并了解ClearCase UCM概念的項目經(jīng)理與架構(gòu)師；Rational工程師的及時支持。

配置管理工程師在這3-4周時間內(nèi)要沒有其他的任務(wù)的打擾，全部的時間應(yīng)用于該項目的配置切換；每個項目在配置切換的準(zhǔn)備階段如果有Rational工程師的現(xiàn)場支持會少走許多彎路。

為了更好的完成工作，配置管理工程師必須經(jīng)過系統(tǒng)的ClearCase的培訓(xùn)，同時為了提高配置管理工程師的能力，建議在內(nèi)部建立一個獨立的試驗環(huán)境，可以讓配置管理工程師從安裝配置Server開始，進行ClearCase的各種功能的操作試驗，以獲得經(jīng)驗。

2.2 準(zhǔn)備
如果決定應(yīng)用ClearCase，好的計劃與充分的準(zhǔn)備會起到事半功倍的效果。一個項目從啟動應(yīng)用ClearCase則相對于從其他配置管理解決方案遷移到ClearCase在準(zhǔn)備上要容易的多，包括多個版本分支的產(chǎn)品的配置遷移則更加困難，如果準(zhǔn)備不充分，可能會造成多次反復(fù)、嚴(yán)重降低工作效率，甚至可能會造成版本錯誤等嚴(yán)重后果。

首先，要決定是應(yīng)用ClearCase UCM還是Base ClearCase，UCM模式是基于Base ClearCase應(yīng)用Activity管理變更的一種模式。如果項目組全部在UNIX上進行開發(fā)，比較熟悉CVS，對命令行及Shell很熟悉，項目團隊配合時間較長，有專職配置管理工程師，建議應(yīng)用Base ClearCase，但是需要自行開發(fā)腳本，以利于項目組成員的使用；跨平臺項目、配置管理工程師是與其他項目共用的、需要對項目的進度與活動有較高的透明度等建議應(yīng)用UCM模式。本文主要探討UCM模式。

在準(zhǔn)備的時候要確定當(dāng)前項目與其他的項目的關(guān)系，以確定PVOB的建立，如果項目和其他項目的關(guān)系不是很緊密，建議創(chuàng)建一個獨立的PVOB。因為一般PVOB不占用過多的資源。

2.2.1 配置模式

PVOB建立完成后，要根據(jù)項目的實際情況確定項目的開發(fā)模式，這里給出一些建議。

2.2.1.1 共享流模式

項目只有一個單獨的集成流，沒有開發(fā)流。適用于調(diào)研項目或規(guī)模較小，且目標(biāo)單一，不會同時有多個變更存在的項目。比較大的項目也可以在實際項目的初始階段建立一個UCM Project，采用共享流模式，在需求完成后，在這個Project的Component上建立Final基線，在這個基線上建立一個新的多開發(fā)流模式的UCM Project進行設(shè)計與編碼。

優(yōu)點：控制簡單，如果設(shè)置的是Dynamic View，每個人的修改，其他人可以立即看到，不需要deliver，對有大量文檔的項目較適合；不需要針對Deliver及Rebase設(shè)置大量的基線，配置管理人員的工作相對較少；同時項目配置管理的Policy也比較簡單，不需要考慮太多。

缺點：如果同時支持多個不同的客戶或同時有多個變更，這些變更之間互相影響，則會產(chǎn)生開發(fā)的混亂。

在Clearcase中共享流模式也支持同時多個用戶對同一文件進行Check out操作，并在Check in時進行歸并。但是如果多人對一個Element進行Check out操作時，只有一個人可以應(yīng)用Reserved checkout，其他的項目組成員只能進行Unreserved Checkout。Reserved Checkout保證了開發(fā)人員是在新的一個版本上進行Checkout，只有在Reserved Checkout的人Check in之后才可以Check in并進行歸并。Reserved與Unreserved的區(qū)別可見圖一。