1. 程式人生 > >ClearCase完全攻略(一):Base和UCM的前生後世

ClearCase完全攻略(一):Base和UCM的前生後世

  • ClearCase到底是幹嘛的?

通俗的我們可以認為是一款IBM出的原始碼管理工具。

  • ClearCase的四大功能?

(版本管理+過程管理+工作空間管理+bulid管理)有個經典的圖,各個功能圖裡面說的很清楚了。

  • Base和UCM到底有什麼區別?

Base 就是Clearcase產品最早自帶的一個原始碼管理模型。可以理解為和其他原始碼管理工具功能類似的一個模型。姑且可以稱為第二代理論。採用分支來支援並行開發。和其他原始碼管理工具沒實質上的區別。

UCM ,可以理解為IBM在軟體工程領域的一個突破。他們稱為的第三代理論,最佳實踐。他們自己走的比較靠前。自定義了一套模型。通俗的講就是把軟體過程分為了:活動+變更集。有個經典的圖,各個功能圖裡面說的很清楚了。update:2010-07-08:

使 用活動管理變更集,提升抽象級別。基於構件組織工件,利用程式碼重用。

(UCM的深入理解,文章一文章二 。其實主要不要把UCM簡單理解為Clearcase和Clearquest的整合就行了。它就是一個模型

有閒工夫,可以用Base實現UCM模型。)

目前的Clearcase同時支援這兩套模型。

  • Base和UCM的選擇問題?

任何公司決定使用Clearcase產品,必然面臨著兩種模型的選擇。到底是Base好還是UCM好呢。老實說兩個都不好用 如果好用,IBM一年一百多萬的服務費找誰去要。那麼多軟體服務公司找誰去收錢。不過大體的趨勢是UCM,

UCM 發展了這麼多年算是比較成熟了。畢竟IBM搞出的第三代理論。他不推誰幫他推。所以說UCM是今後的發展趨勢絕不為過。。缺點是模型已經給你搭建好了。可擴充套件性不強。不過優點顯而易見,和Rational的其他產品比如ClearQuest無縫整合。基本上不用再怎麼code。

Base 的話什麼零件都有,不過什麼都要自己組裝。需要自己公司花費些人力物力構建個適合自己公司的模型。對SCM的要求稍微有些高。和Rational的其他產品的整合也是老廢功夫。不過一些老的Clearcase產品使用者還是繼續使用這個模型(一些老牌的牛逼企業)。畢竟想讓他們更換比較不現實。

當然最後要說的是。仁者見仁智者見智。選擇那個都可以達到管理的目的。關鍵是那個更適合。更經濟更有效。

  • Clearcase物件介紹?

已經說了UCM和Base是兩套完全不同的理論,所以UCM的概念是Base的加強版。雖然大同小異,不過還是有區別。我們先介紹Base的。(以後的不註明UCM的,預設就是Base的概念)

update:2010-07-23 cj整理

一般的ucm流程
1.    cc管理員建立vob
2.    專案經理建立ucm project
3.    開發人員加入ucm project
4.    開發人員進行開發
5.    開發人員deliver工作成果到共享區域(整合流)
6.    釋出工程師構建釋出產品
7.    專案經理建立基線
8.    專案經理在里程碑處提升基線等級
9.    開發區人員在私有空間獲取最新的推薦基線

一般Base的流程
1.    專案經理建立專案環境
a)    建立vob
b)    定義分支策略
c)    建立共享檢視和標準的配置規約
d)    定義檢視名稱規範
2.    專案經理執行開發策略
a)    定義標籤
b)    定義屬性
c)    使用hyperlinks
d)    使用triggers
e)    使用locks
3.    定義全域性型別
4.    建立歸併策略
5.    開發人員進行開發
6.    開發人員提交工作成果到整合分支
7.    釋出工程師構建釋出產品
8.    專案經理打標籤
9.    開發區人員將標籤程式碼歸併到開發區分支