姜 文,劉立康
(西安電子科技大學 通信工程學院,陜西 西安 710071)
基于ClearCase的軟件配置管理與持續集成
姜 文,劉立康
(西安電子科技大學 通信工程學院,陜西 西安 710071)
軟件配置管理是整個軟件開發生命周期中一個核心的管理過程。ClearCase是業界非常優秀的軟件配置管理工具,主要應用于復雜環境下的軟件產品開發和維護工作,適合大型軟件團隊使用。ClearCase可以實現并行開發,提高軟件開發效率。文中敘述了配置管理工具ClearCase的特點;介紹了ClearCase軟件配置管理的基本概念和相關角色;詳細介紹了配置管理的工作流程,主要包括權限管理、ClearCase控制管理下的開發工作、建立編碼基線、構建內部轉測試版本、變更管理、版本管理等內容;詳細介紹了基于ClearCase配置管理的持續集成;最后介紹了一個典型工作案例。工作實踐表明,采用該配置管理方法有助于提高軟件質量和工作效率,也便于管理工程師及時了解工作進度和解決存在的問題。
版本對象庫;配置管理;視圖;流;基線;持續集成
軟件配置管理在軟件項目開發過程中起著至關重要的作用。ClearCase是業界非常優秀的軟件配置管理工具。采用ClearCase進行版本控制可以實現并行開發,提高軟件開發效率。ClearCase采用兩種應用方式:UCM ClearCase和Base ClearCase。UCM ClearCase提供了更加完善的功能,主要應用在大型軟件項目的開發。Base ClearCase易于掌握,適用于中小型軟件項目的開發。
持續集成是完全的自動化構建過程。它的特點是代碼提交頻率高,構建頻率也高,實現快速反饋。從而可快速修復代碼中的缺陷,提高代碼質量;加強工程師溝通,明確工作進度,給項目管理提供了很好的保證。
文中主要介紹的是UCM ClearCase,詳細介紹了基于ClearCase的軟件配置管理和持續集成,最后介紹了一個典型工作案例。
1.1 特點描述
軟件配置管理工具ClearCase主要用于Windows和Unix開發環境。ClearCase主要有以下特點和功能:
(1)版本控制(Version Control)。
ClearCase可以對軟件開發環境中的各種對象類型進行版本控制,其中包括源代碼、二進制文件、可執行文件、文檔、目錄內容、測試相關文件、編譯器等;可以自動追蹤文件和目錄的變更情況。ClearCase具有分支和歸并功能,從而支持并行開發。版本的組織是通過圖形化的版本樹來體現的,可以通過版本樹查閱配置項任一版本的情況。
(2)工作空間管理(Workspace Management)。
ClearCase提供兩種視圖。動態視圖(Dynamic view)提供網絡用戶快速取得軟件代碼和文檔資料。靜態視圖(Snapshot view)提供用戶下載軟件代碼和相關資料,支持局部構建和離線作業。
具有快照(snapshot)和分支(branch)功能,使版本控制的功能進一步增強??煺帐琼椖恐卸鄠€配置項各自的當前版本的集合,能方便地恢復配置項早期版本,支持批量檢出、檢入等操作。用戶可以創建獨立的開發路徑,進行并行開發和多版本開發。
(3)構建管理(Build Management)。
ClearCase可以選擇構建的文件版本,記錄軟件構建過程的相關信息;可以重建任何以往的版本;可以并發執行多個構建腳本來完成軟件版本構建。自動建立system build清單,與一般常用的nmake及GNU make兼容。
(4)過程控制(Process Control)。
在軟件開發過程中,ClearCase可以通過權限管理對開發工程師授予不同的權限來控制對文件或目錄的各種操作。可以自動生成常規日志,監控軟件的變化情況。可以提供開發工程師開發活動的定制安排,使軟件開發過程的管理趨于自動化。
1.2 搭建配置管理的軟、硬件環境
ClearCase配置管理的硬件環境主要是由服務器和客戶端組成,采用C/S網絡結構。
1.2.1 服務器端安裝配置
服務器端由VOB/View服務器、注冊(Registry)服務器、許可證(License)服務器和ClearQuest[1-3]數據庫服務器組成。若使用ClearCaseWEB客戶端,則還需安裝ClearCaseWEB服務器,通常ClearCaseWEB服務器和View服務器會配置在同一臺機器上。
由于ClearCase利用Windows的域來進行用戶的權限管理,首先在一臺服務器上預安裝ClearCase,新建一個域。在ClearCase預安裝完成后,會自動創建一個具有超級權限的管理員組(ClearCase組,CC組)和有超級權限的用戶clearcase albd,clearcase albd屬于CC組。CC組的成員稱為CC管理員。
以CC管理員身份安裝各種服務器軟件。對于有多個大項目的團隊來說,通常配置多臺ClearCase服務器。CC管理員可以在VOB服務器創建項目PVOB,根據項目需要,可以建立多個VOB。創建新項目后可以將相關的源文件導入VOB。
1.2.2 客戶端安裝配置
(1)將本機加入ClearCase所在域;
(2)將登入本機的域用戶加入本機管理員組,使該用戶擁有本機管理員權限;
(3)該用戶在本機上以默認設置完成ClearCase客戶端安裝。
客戶端是提供給開發工程師的終端平臺。
2.1 ClearCase基本術語
(1)元素[4-5]。
元素由版本控制下的文件和目錄組成。文件元素是可以儲存在文件系統中的任何文件。目錄元素中包含著文件元素及其他目錄元素。
在ClearCase中沒有提到軟件配置管理中常用的概念配置項(Configuration Item,CI),配置項是軟件生存期內,能相對獨立開發的一個程序實體或文檔。
配置項和元素之間的關系:元素是軟件配置項的載體,配置項是元素存儲的內容。
(2)版本(Version)。
版本是指元素的某一特定時刻存儲的內容。元素的一個檢入(Check in)產生一個新的“版本”,元素的版本號增加1。元素記錄了它所代表的文件或目錄的所有版本。
(3)工作空間。
工作空間稱為“視圖(view)”。ClearCase提供了兩種視圖。靜態視圖將文件下載到視圖中,通過數據庫跟蹤下載到工作目錄中的文件版本。動態視圖通過虛擬文件系統提供對于元素版本的存取操作,不需要將元素拷貝到本地目錄中。
(4)版本對象庫(Version Object Base,VOB)。
版本對象庫簡稱版本庫,VOB是軟件配置管理(SCM)系統的核心,用來存儲文件、目錄和元數據的永久數據存儲池。
ClearCase有兩種VOB,項目PVOB(Project VOB,PVOB)和標準VOB。PVOB用來組織和管理正在開發的項目,一個PVOB可以有多個VOB。VOB用于正在開發的系統。
通常邏輯上版本庫可以分為開發庫(動態庫、程序員庫、工作庫)、受控庫(靜態庫、主庫)、產品庫(軟件倉庫)3種。
(1)開發庫:存儲開發過程中的源代碼、可執行代碼、數據和相關的技術文檔,為開發工程師的工作提供支持。
(2)受控庫:存放處于受控狀態的基線庫和其他軟件產品。
(3)產品庫:項目交付用戶的軟件產品和相關的運行環境。
2.2 UCM術語
(1)項目(Project)。
UCM項目[6]是開發團隊為執行開發活動而進行代碼或其他配置項修改的協作環境。ClearCase中基本UCM項目由一個共享工作區和多個私人工作區組成。
(2)構件(Component)。
構件通過一個根目錄來定義。將開發團隊進行開發的文件和目錄組合在一起就形成了構件。開發團隊以構件為單位進行開發、集成和發布。一個VOB可以包含一個或多個構件。
(3)活動(Activity)。
活動用于跟蹤完成一項開發任務的工作,它記錄了開發工程師為完成或交付某個開發任務而創建或修改的文件集合(變更集)。
(4)基線(Baseline)。
構件的一個版本就是一個基線?;€用于標識構件中各個元素的某個版本。它代表了構件在項目開發某一特定階段的一個版本。
基線是下一步開發的出發點(見表1)?;€的變更受到嚴格控制。在一個軟件開發過程中,上一個基線加上新的內容形成下一個基線。

表1 軟件開發過程中的主要階段基線及 相應的軟件配置項列表
設計階段基線,通常以文檔的形式存在。實現階段基線,包括文檔、代碼和可執行程序。
(5)工作區和流。
工作區是與變更相關的開發區域。而在UCM中工作區則由視圖和流組成。
流是一種ClearCase對象,UCM定義了兩種流,分別是開發流(Development Stream)和集成流(Integration Stream)。開發流主要是那些涉及單個開發工程師的工作的流;而集成流則是那些涉及對一個項目中所有開發工程師的活動進行合并的流。
每個項目通常有一個集成流和多個開發流。對于大型項目可以增加測試流和基線流,見表2。

表2 流與工作區
參與配置管理的相關角色:項目經理(PM)、軟件系統工程師(SE)、配置管理員(CMO)、持續集成工程師(CIE)、軟件開發工程師(DEV)、軟件測試工程師、質量保障工程師(QA)、資料工程師。
其中,項目經理、軟件開發經理、軟件測試經理、系統工程師、配置管理員、質量保障工程師組成配置控制委員會(Change Control Board,CCB)。
CCB的職責:審核各種變更申請;建立、更改基線的設置;定制訪問控制;負責指導配置管理的各項活動,為項目經理的決策提供建議。
軟件項目開發可以分為三個階段:計劃、開發和產品維護。對于配置管理來說,后兩個階段所涉及的活動基本相同,可以合并為開發和維護階段。
4.1 UCM工作流程
ClearCase提供UCM[6]和Base兩種軟件開發模式。Base ClearCase是基于文件的管理方式,UCM方式則主要采用Activity方式進行項目管理。UCM在Base ClearCase的基礎上提供了高層抽象,簡單易用。
ClearCase UCM模式是一種基于Activity的開發過程,項目經理負責創建項目。一個項目通常包括公共區、集成測試區和多個私有工作區。項目經理負責維護項目公共區域,集成測試工作人員在集成測試區工作,開發工程師在私有工作區獨自進行工作。
UCM工作流程包括三個軟件循環開發過程:項目管理循環、開發循環和集成測試循環,如圖1所示。
4.2 編制配置管理計劃
配置管理計劃主要描述配置管理的組織機構、職責和接口、版本庫的結構、配置管理環境的建立、訪問權限設置、基線的建立、各個里程碑處所提交的工作產品及提交時間、變更控制及配置狀態統計等內容。

圖1 UCM工作流程圖
4.3 權限管理
ClearCase本身不具有管理用戶的功能,而是通過Windows系統中的域來管理用戶。與Unix文件管理系統類似,每個VOB里的目錄和文件的權限控制都基于owner、group和other,訪問模式分為r(讀)、w(寫)、x(執行)。
ClearCase安裝完成后,會自動創建一個具有超級權限的用戶組CC組。配置管理員屬于該組,對ClearCase管理具有最高的權限。ClearCase按組來設置權限,每個用戶可以屬于幾個組,但只能屬于一個主組。對于一個ClearCase對象,其owner和配置管理員有最高權限。配置管理員負責項目組的權限管理,見表3。
4.4 ClearCase控制管理下的開發工作
配置管理員首先建立一個PVOB,然后在這個PVOB下面創建子VOB。項目經理將源文件導入VOB,通知、指導開發工程師加入創建的項目。開發工程師在客戶端的ClearCase Explorer中,用Join Project來加入到這個UCM項目。每個開發工程師創建自己的工作區(開發流和開發視圖)。
在客戶端ClearCase Explorer選擇“MyActivities”,開發工程師可以看到自己要處理的Activity。開發工程師針對被分配的活動(工作任務)進行工作。
開發工程師每天主要工作如下:
根據集成流提供的新基線更新(Update)工作區代碼。
檢出(Check out)自己需要的文件開始工作。提供新的源代碼或對原來的代碼進行改進,同時對代碼進行單元測試,靜態走碼檢查,沖突處理和本地構建工作?,F在一些開發工程師采用測試驅動開發的方式編寫代碼。

表3 軟件項目開發過程中的權限管理
最后將評審過的代碼檢入(Check in)到集成流。開發工程師向VOB提交代碼時,要添加注釋、說明、CR單號、修改原因等,以保證可追溯。
4.5 開庫和鎖庫
配置管理員負責每天版本庫的開庫和鎖庫,開庫和鎖庫主要是針對集成流。每天開庫將集成流相應的權限賦予項目組成員。開發工程師完成代碼提交后,鎖庫取消項目組成員的相應權限,僅保留配置管理員和持續集成工程師的權限,以便持續集成工程師完成集成構建工作。
4.6 持續集成建立編碼基線
配置管理員鎖庫后,持續集成工程師從集成流檢出新提交的代碼。啟動CI服務器對新提交的代碼結合原有項目資源開始構建工作。采用增量構建,快速創建一個新版本;自動執行一系列測試(單元測試、靜態測試和一些耗時的代碼審查任務等)。自動執行冒煙測試(在集成測試環境中自動執行核心的測試用例),來驗證新提交的代碼有沒有對項目造成破壞。若構建成功,建立新的編碼基線,通過電子郵件通知項目經理和開發工程師。若構建失敗,不更新基線,通過電子郵件通知項目經理和相關的開發工程師對提交的代碼進行及時修改。
4.7 構建內部轉測試版本建立測試基線
通常選擇每周執行一次構建內部轉測試版本。持續集成工程師從集成流取得新提交的代碼后,執行全構建任務。全構建任務執行時間較長,有些工作還需要手動執行。啟動CI服務器執行所有的構建任務,通常包括環境清理、更新代碼、編譯、測試、代碼審查、打包、部署、性能測試等。生成的軟件版本放在測試流中并標記版本號,提交轉測試流程。由測試經理組織進行版本驗證;測試工程師進行各種測試,包括功能測試、性能測試等,測試中發現問題,知會項目經理和開發工程師及時處理。完成內部轉測試版本測試,就建立了新的測試基線,同時也建立了新的編碼基線(Tested),和每日構建建立的基線相比由內部轉測試版本建立的基線等級要高一些。配置管理工程師執行基線化的操作,并發布基線建立的報告。
4.8 變更管理
變更管理是軟件配置管理的三大核心之一。ClearCase通過與ClearQuest集成提供變更請求管理和缺陷跟蹤管理。
ClearCase同ClearQuest的集成是通過ClearCase的版本庫(VOB)關聯ClearQuest的數據庫來實現。ClearQuest可以捕獲和跟蹤各種類型的變更請求(例如產品缺陷、功能增強、文檔更新等)。ClearQuest提供最佳的變更請求管理解決方案。這使得開發團隊可以更容易管理各種類型的變更。UCM模式中的變更和缺陷管理是基于活動來完成的,整個工作流程由ClearQuest提供。
4.8.1 變更請求管理
在軟件研發過程中會遇到4類變更請求:需求變更、計劃變更、設計變更以及工程變更。
變更管理流程:
以上提到的4類變更請求,都采用一個通用的變更管理流程。
主要由以下6個步驟組成:
(1)提交:首先提交變更申請,在申請中詳細描述變更的范圍、原因和依據,變更的優先級,變更的影響,建議的變更方案和替換方案。
(2)評估:CCB收到變更請求之后,對請求進行評估和分析,識別和評估受影響的所有配置項,確定修改方案、修改人、修改版本、修改時間、驗證方式和驗證人。必要時邀請相關受影響的工程師參與評審。
(3)決策:接受的變更請求,由配置管理員負責授權。
(4)實現:修改人執行變更并驗證。
(5)驗證:之后,由CCB指定的驗證人對變更進行驗證。
(6)完成:驗證通過后,CCB確保修改驗證合格的配置項合入版本庫,然后關閉變更請求并發布。
ClearCase UCM通過ClearQuest對變更活動進行提交、評估、決策、實現、驗證和完成,從而實現變更的自動化管理。運用ClearQuest可以方便地跟蹤、管理相關的變更請求,充分掌握變更的現狀。
4.8.2 缺陷跟蹤管理
ClearQuest對缺陷處理過程進行自動跟蹤,從BUG提交到關閉,記錄了BUG所有的改變歷史。項目經理可以及時查詢各種BUG的狀況,可以在ClearQuest中創建缺陷處理的活動,把任務分配給開發工程師處理。開發工程師在自己的開發視圖中,通過MyActivities菜單選項可以看到分派給自己的任務,根據測試人員對缺陷的描述,修復相應缺陷。項目經理可以查看缺陷處理的狀況,跟蹤缺陷修復的過程。
4.9 配置狀態發布
配置狀態發布是建立與維護配置項的記錄;為相關工程師提供準確的配置信息;通過記錄和報告變更請求的狀態,為產品的質量、進度、趨勢等提供數據。
配置狀態發布的主要內容包括:配置項狀態、基線發布情況、版本發布情況、變更管理情況、版本庫以及權限情況。
4.10 版本管理
版本是產品或者解決方案在不同時間段的特性集合,一個產品或解決方案可以有多個版本。
4.10.1 版本管理流程
版本包括內部轉測試版本(Tested)以及對外發布版本(Released),項目開發任務完成后,測試流中最終的版本成為對外發布版本(Released),提供給客戶使用。
版本管理的過程如下:
(1)項目經理將制定評審版本計劃,包括內部轉測試版本以及對外發布版本。
(2)開發工程師和資料工程師完成源代碼開發和文檔編寫。
(3)持續集成工程師對代碼進行每日構建工作,每周完成內部轉測試版本構建。
(4)提交轉測試版本,由測試經理組織進行版本測試和驗證。
(5)開發活動完成之后,由配置管理員準備最終的產品版本,以及版本文檔、產品文檔、版本光盤包等;提供給測試經理,組織進行最后的版本測試和驗證。
(6)測試和驗證通過之后,配置管理員提交對外發布版本,由項目經理組織各領域的代表評審,確認版本符合發布要求。
(7)進行正式的版本發布流程,版本最終傳遞給客戶。
版本的管理流程如圖2所示。
4.10.2 配置管理的移交
配置管理的移交活動通常發生在產品開發結束的GA點(即產品由開發狀態轉為維護狀態之后)。配置管理員需要完成以下工作:
(1)整理、歸檔數據、代碼(包括可執行文件)和文檔;
(2)歸檔或刪除項目配置庫;
(3)移交產品配置庫。
現在軟件開發通常采用持續集成(CI)[7-14]技術。CI服務器可以自動檢查動態庫的變化,設定時間區間,定時自動完成集成構建工作,并以郵件的形式向整個開發團隊反饋集成構建結果。幾個小時就可以完成一次集成構建,一次構建通常可能包含編譯、測試、審查和部署,以及其他一些事情。本節以ICP-CI服務器為例介紹持續集成。
5.1 安裝持續集成工具
(1)根據開發項目的代碼規模、編譯環境、編譯工具來選擇CI服務器的CPU、內存等硬件配置和操作系統。一套CI服務器很可能同時承擔多個軟件產品的持續集成工作。
(2)ICP-CI服務器系統有兩種常見的部署形式,分別是單機式和分布式。
單機式指的是整套CI服務器系統由一臺服務器組成,該服務器自主完成持續集成任務,這種系統適用于代碼量小于一百萬行的開發團隊。
分布式指的是整套CI服務器系統由一臺主控服務器和多臺代理服務器組成,將持續集成任務下發到各個代理服務器上,任務完成之后將任務結果和日志文件發回到主控服務器,這種方式適用于代碼量大于百萬行的開發團隊。
(3)安裝持續集成工具ICP-CI,根據編譯環境的不同持續集成工具ICP-CI可以分為不同的版本。在Windows環境下,主控服務器部署工具為ICP-CI-Windows-Master,代理服務器部署ICP-CI-Windows-Agent。在Linux環境下,主控服務器部署工具為ICP-CI-Linux-Master,代理服務器部署ICP-CI-Linux-Agent。持續集成工具ICP-CI是跨平臺的,主控服務器和代理服務器可以選擇不同的操作系統。通常主控服務器選擇Windows環境。
(4)ICP-CI工具在安裝的過程中需要解壓安裝包安裝。對于ICP-CI-Windows-Master,需要進入ICP-CI-Windows-Master下的master目錄中,執行批處理啟動MYSQL數據庫之后,啟動ICP-CI的網頁版頁面。對于ICP-CI-Windows-Agent和ICP-CI-Linux-Agent將安裝包解壓之后,需要將安裝ICP-CI-Windows-Master的服務器IP地址配置到agent目錄下conf文件夾對應的配置文件中,再執行批處理腳本啟動代理服務器的CI進程。
5.2 安裝ClearCase客戶端工具和創建代碼視圖
CI服務器需要安裝ClearCase客戶端工具。完成ClearCase客戶端工具的安裝之后,就可以根據配置管理員提供的產品代碼動態視圖和視圖規則,使用ClearCase客戶端工具創建視圖,從版本庫下載代碼到代理服務器的指定路徑下。
5.3 搭建構建工程
打開ICP-CI網頁的頁面,創建產品的構建工程,使用ANT腳本完成出包腳本。構建工程創建成功之后,分別配置更新代碼、靜態檢查、進程編譯、出包、用例測試等步驟。
5.3.1 代碼更新
在ClearCase版本庫鎖庫之后,將開發工程師提交到ClearCase版本庫的所有代碼通過命令行工具中的更新命令“Cleartool update”更新到代理服務器的視圖中。
5.3.2 靜態檢查
對于產品的代碼是使用C/C++來編碼的,采用的靜態檢查工具為Pclint。根據產品的模塊編譯分成不同的*.lnt文件,用模塊名用來命名*.lnt文件。*.lnt文件中需要配置該模塊的相關代碼路徑。在配置對應模塊的Pclint任務時,將*.lnt文件配置進去。
5.3.3 編 譯
各模塊的編譯腳本和編譯類型需要在ICP-CI的任務頁面上完成配置。產品代碼在編譯過程中可以查找開發工程師在編碼過程中沒有關注到的編譯錯誤。編譯為下一步的出包步驟生成進程文件。

圖2 版本的管理流程
5.3.4 出 包
出包任務在編譯任務完成之后,根據全部編譯任務提供的進程文件,在ICP-CI的任務頁面上完成對出包的ANT腳本配置,生成版本包。將版本包部署到相應的目錄下。
5.3.5 測試用例
在ICP-CI頁面完成對測試用例任務的配置。在測試用例環境下對版本包進行自動化測試,完成版本包的初步測試。
某公司有一個軟、硬件結合的大型軟件開發項目,采用的ClearCase版本是7.0.1。持續集成主控服務器操作系統為Windows 2003 Server,代理服務器操作系統為Windows 7。參與持續集成的服務器共20臺,1臺主控服務器和19臺代理服務器。采用批處理腳本和ANT腳本編程完成軟件的持續集成構建工作(完成進程編譯、靜態檢查和版本出包等任務)。工作實踐表明,采用基于ClearCase的配置管理和持續集成有助于提高軟件質量,也便于項目經理和開發工程師及時了解工作進度和解決存在的問題。
長期的工作實踐表明,配置管理在軟件開發過程中占有重要地位。采用持續集成進行自動化構建可以使配置管理工作更有效率,有助于減少開發中埋藏BUG的風險,從而提高軟件質量;同時也便于項目經理和開發工程師及時了解工作進度和解決存在的問題。應用軟件的配置管理工作做好了,將很大程度上提高軟件質量,降低軟件開發成本,推動軟件產業的健康發展。
[1] 劉文紅.CMMI項目管理實踐[M].北京:清華大學出版社,2013.
[2] 劉江華,王 立,馬 玲,等.軟件開發過程與配置管理:基于Rational的敏捷方案設計與應用[M].北京:電子工業出版社,2011.
[3] 袁肅蓉,王 萍,黃萬民,等.基于ClearCase的軟件配置管理環境的規劃和實施[J].海南大學學報:自然科學版,2009,27(1):54-59.
[4] Bellagio D,Milligan T.Software configuration management st-rategies and IBM rational ClearCase:a practical introduction[M].2nd ed.USA:IBM Press,2005.
[5] Lee K A.IBM rational ClearCase,ant and CruiseControl[M].USA:IBM Press,2006.
[6] Tykal J.Best practices for using composite baselines in UCM[R].[s.l.]:PrentieeHall,2004.
[7] McConnell S.Daily build and smoke test[J].IEEE Software,1996,13(4):143-144.
[8] 羅時飛.敏捷持續集成(CruiseControl版):高效硏發之道[M].北京:電子工業出版社,2008.
[9] 韓萬江,姜立新.軟件項目管理案例教程[M].第2版.北京:機械工業出版社,2009.
[10] Duvall P M,Matyas S,Glover A.持續集成軟件質量改進和風險降低之道[M]. 北京:電子工業出版社,2012.
[11] 李 進.某公司軟件持續集成改進的分析設計及實施[D].北京:北京郵電大學,2012.
[12] 徐仕成,楊邦榮.基于CruiseControl的持續集成實現方案[J].計算機與數字工程,2007,35(4):169-171.
[13] 吳 奕.軟件配置管理工具在大型網站開發中的應用[D].上海:復旦大學,2011.
[14] 楊宏英,林長松.基于IBM Rational ClearCase的配置管理及應用:中國軟件行業協會[C]//CSSPI2006第五屆中國系統與軟件過程改進年會論文集.北京:出版地不詳,2006:156-162.
Software Configuration Management and Continuous Integration Based on ClearCase
JIANG Wen,LIU Li-kang
(School of Telecommunication Engineering,Xidian University,Xi’an 710071,China)
Software configuration management is a core management process in the entire software life cycle.The ClearCase,a configuration management tool,is mainly used for the software product development and maintenance in complex environment,which is suitable for large software team.ClearCase can realize the parallel development,improving the development efficiency.The characteristics of ClearCase was described,the basic concept of the configuration management and the related roles was introduced,the work flow of it was discussed in detail,manly including rights management,the development under the ClearCase,the code base establishment,internal test version construction,version management,etc.Introduce in detail configuration management and continuous integration based on the ClearCase.Finally give a typical case.Practice shows that using this method helps to improve the quality of software configuration management,also facilitate managers understand the work progress and solve the problems in time.
object library of version;configuration management;view;flow;baseline;continuous integration
2015-04-28
2015-08-05
時間:2016-01-04
國家部委基礎科研計劃:國防預研基金項目(A1120110007)
姜 文(1986-),女,工程師,碩士,CCF會員,研究方向為圖像處理和模式識別、數據庫應用、軟件工程等;劉立康,副教授,研究方向為數字通信、圖像傳輸與處理、圖像分析與圖像識別等。
http://www.cnki.net/kcms/detail/61.1450.TP.20160104.1505.022.html
TP311.56
A
1673-629X(2016)01-0010-08
10.3969/j.issn.1673-629X.2016.01.003