我的測試生涯（1）——開篇《Clearcase簡介》

標籤：style   blog   http   color   使用   io   strong   檔案   

一、前言

　　畢業之前想的是做開發工作，結果陰差陽錯的被分在了測試部門，分都被分了，那就從測試開始幹起吧。　　

　　工作也快兩個月了，這兩天第一次接觸到原始程式碼控制這一名詞，那就從這談起吧

　　原始程式碼控制也稱為軟體組態管理（Configuration Management），是通過技術或行政手段對軟體產品及其開發過程和生命週期進行控制、規範的一系列措施。

　　常見的軟體組態管理工具有：VSS、SVN、Clearcase，因為筆者也是初學者，以前在學校做項目，因為項目規模不是很大，對代碼的管理（合并、刪除、版本）只是採用copy，兼具使用日期（比如今天要完成一個功能，就會將以前的代碼copy一份，並在原有的基礎上開發信的功能，並且以今天的日期140808來命名）命名的方式所進行的，從來沒有接觸到代碼管理的概念，顯然這樣的方式對於規模比較大，代碼量大的項目來說肯定是行不通的。

　　通過這兩天的培訓，第一次接觸到代碼管理的概念，進而覺得對代碼的管理師很有必要的。因為培訓課程講的是Clearcase，那我們就從Clearcase開始我們的代碼管理過程吧。

二、Clearcase簡介

　　 Clearcase是由Rational公司開發的，後來Rational公司被IBM收購後，現在人們一般說Clearcase是一款IBM出的原始程式碼控制工具。

　　ClearCase通過TCP/IP來串連用戶端和伺服器。

　　ClearCase擁有的浮動License可以跨越UNIX和 Windows NT平台被共用。

　　ClearCase主要應用於複雜產品的並行開發、發布和維護，它可以提供：

                      •管理多樣化的版本       •跟蹤版本       •保證軟體元素的完整性      •實現同步開發環境      •精確重現每一次發布 

其功能劃分為四個範疇：版本控制（Version Control）、工作空間管理（Workspace Management）、構造管理（Build Management）、過程式控制制（Process Control）。

 

 

圖1 Clearcase四大功能

　　Clearcase分為兩大模式：Base和UCM，這兩種模式各有各的好處，但是現在大多數用的是UCM（這裡只是個人感覺）

2.1 Clearcase基本對象

• VOB（Version Object Base）——版本物件程式庫

　　VOB是一個特定的資料庫系統，其可以①儲存有版本的資料；②可以被mount的檔案系統；③儲存資料的曆史版本；④防止資料被非法修改；⑤可以儲存資料的類型包括：檔案 、目錄

　　VOB中存放的內容都具有版本的概念，這方便使用者可以回溯到以前的任何版本進行相關操作

　　一個項目可以跨越多個VOB，多重專案可以共用同一個VOB

• element——元素

　　element包括檔案和目錄（都具有版本的概念）

• Version——版本

　　Version是一個element的其中一個版本，多個版本一起就組成了這個element的版本樹

 

圖2 VOB、element、version三者之間的關係圖

• view——視圖

　　view是開發人員用來訪問VOB的視圖工具

　　view可以形象的理解為：照相機的鏡頭（或者濾鏡）

　　view通過某種規則來擷取VOB中元素的某個版本，並組成了作業系統中的目錄結構

　　view其實是“開發人員的工作空間”

 

圖3 view的功能圖解

　　view分為動態view和靜態view（也稱為快照view），各自的優缺點如下：

 

　　　　 動態視圖，是動態將CC伺服器中的內容同步到開發人員的機器中，這就要求開發人員一直與伺服器保持串連。

　　　  靜態視圖，是將CC伺服器中的視圖內容拷貝到開發人員的機器中，開發人員需要經常與伺服器同步以保持資料的一致性，快照視圖的好處在於開發人員不必一直通過網路與CC伺服器保持串連；但是如果要與伺服器同步必須update view。

• branch——分支

　　branch是在某個元素的某個版本處拉出的一個枝幹，其主要用於開發人員的並行開發以及Bug的修複（bugfix）

　　套建立branch執行個體之前，必須建立branch類型

• Label——標籤

　　Label是在某個元素上用具有一定意義的字串來標識某個特定版本的，以便開發人員（或Leader/Manager)檢索和組織軟體代碼和文檔

 　 一個元素可以產生多個版本，label打到特定的版本上，你取到的代碼就是唯一的

圖4 branch與Label圖示　　

• PVOB（Project Version Object Base）——Project版本物件程式庫

　　PVOB是UCM（Unified Changed Management，統一變更管理模式）是在base的基礎上新增的，用於儲存 UCM 所需要的一些特殊的資訊，如Proejcts，Stream，Activity及Change Sets等，一個PVOB可以包含多個Project的資訊，Project的資訊必須儲存在PVOB中

• stream

　　stream也是UCM新增的，其分為整合流（Integration stream）和開發流（Develop stream）

　　Integration stream可以理解為項目的主幹，通常也稱為幹流，每個開發流都是整合流的一個分支

　　在一個項目的Integration stream上可以拉出許多子流，開發人員可以再這些子流上開發相應的功能，開發完成後，將開發成果再提交到整合流上去，在整合流上整合管理員根據提交的內容進行編譯，測試以後在整合流上打上基準（baseline），等所有的測試通過以後可以推薦基準

• Project

　　Project是也UCM在base的基礎上新增的，包含了組態管理所需要的一些配置資訊，如果Component、Baseline，Stream等，每個Project都有一個Integration Stream 

• config spec

　　config spec就是view中所講到的某種特定規則

　　config spec有三種原則：①從上到下；②從左至右；③復原；

• Component——組件

　　Component也是UCM新增的，可以理解為一些代碼、文檔等按一定的目錄結構組織成的完成某些功能的可以重用的集合

既然Component是一組檔案的集合，則其有三種形式：①一個vob就是一個Component；②一個vob下的根目錄就是一個Component；③虛擬存在的；

• Activity——活動

　　Activity也是UCM新增的，通過變更集(Change Set)跟蹤完成一項開發工作單位所引起的所有配置項的變更

　　在UCM模式下所有的Check Out、Check In等引起配置項發生變化的操作必須關聯到一個Activity 

• Baseline——基準

　　Baseline也是UCM新增的，基準標識了一個組件或多個組件中所有元素的某一個版本和這些元素的活動

　　簡單理解為就是打在多個相關元素上的某一版本的集合

　　可以從基準產生開發流或者為一個已有的開發流基準更新(Rebase)，一個基準是一個構件在一個特定時刻的一個快照

2.2 小結

 

從軟體產品組成角度：

 

• 一個VOB可以包含一個或者多個Component。（PVOB無需包含Component）
• 一個Component包含多個Element（檔案和目錄）
• 一個Element將以版本樹的形式來儲存該Element的多個version
• 在建立Component的時候，將形成一個初始化Baseline（Component_name）_initial.該基準不依賴任何流而存在

 

從軟體如何開發角度：

 

• 一個Project包含一個或者多個Stream。
• 在建立Stream的時候。將選擇該Stream的foundation baseline
• Stream上將包含多個activity
• 一個Stream可以關聯多個view
• view是通過它關聯的Stream來決定所能訪問到的版本

 

 

　註：參考部落格  http://blog.csdn.net/hhg208/article/category/693450