1 簡介

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

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

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

2 計劃與準備

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

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

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

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

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

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

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

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

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

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

2.2.1 配置模式

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

2.2.1.1 共享流模式

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

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

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

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

2.2.1.2 多開發流模式

項目中有多個不同的開發流，每個開發流都是一個獨立的分支，如果項目需要還可以建立多層次的分支，支持并行開發，適于超過10人，較復雜的項目。如果項目極復雜，可以分為多層開發流與集成流，如圖二。優點：可以并行開發，每個Stream都相當于一個獨立的開發環境，每個人之間的工作不會互相產生干擾；可以通過Policy的設置更好的進行配置管理。

缺點：不同的Stream之間的Deliver與Rebase會產生問題；在merge時也有可能會產生問題，而且對Word等二進制文件的merge支持不好；在修改完成之后，每個Stream上的修改只有deliver與Rebase才能被其他的stream應用，不能及時反映變化；Policy的設置較復雜。

在多開發流模式下可以根據需要將某個stream設置為只讀模式。

建議：可以根據需要建立一個多開發流模式的Project，但是在初期階段不設立開發流，在進行詳細設計階段后再建立相應的開發流。

原文轉自：http://www.anti-gravitydesign.com