基于SVN的軟件配置管理和持續集成

姜文，劉立康

（西安電子科技大學 通信工程學院，陜西 西安　710071）

基于SVN的軟件配置管理和持續集成

姜文，劉立康

（西安電子科技大學 通信工程學院，陜西 西安710071）

SVN是一款廣泛使用的配置管理工具，適合中小型軟件團隊使用。本文敘述了SVN的特點，介紹了配置管理的基本概念和相關角色；詳細介紹了基于SVN的軟件配置管理和持續集成，主要包括權限管理、SVN控制管理下的開發工作、建立編碼基線、構建內部轉測試版本、變更管理、版本管理等內容；最后介紹了一個典型工作案例。工作實踐表明采用該管理方法有助于提高軟件質量，便于項目管理者及時了解工作進度和解決存在的問題。

版本控制；配置管理；分支；標簽；基線；持續集成

軟件配置管理在軟件項目開發過程中起著重要的作用。目前國內使用比較多的軟件配置管理工具有 ClearCase、SVN、Microsoft VSS等。ClearCase適合大型軟件團隊使用，SVN適合中小型軟件團隊使用。Microsoft VSS適合小型軟件團隊使用。文中敘述了配置管理工具SVN的特點，詳細介紹了在軟件開發過程中基于SVN的配置管理和持續集成，主要包括權限管理、SVN控制管理下的開發工作、建立編碼基線、構建內部轉測試版本、變更管理、版本管理等內容。

1　SVN的特點

SVN［1-2］是 Subversion的簡稱，是一個開源的配置管理工具。

1.1SVN的特點

1）版本管理

SVN可以跟蹤單個文件和整個目錄樹的變更歷史。SVN會記錄每一次更改，包括增加、刪除和重新組織文件和目錄。每次變更SVN都會將版本號加1，修改文件、添加刪除文件、修改文件夾的SVN屬性，都會更新版本。

2）原子提交方式

一個更改集可以整體作為原子提交，即全部提交到版本庫，或一個也不提交。

3）一致的數據操作

文本文件和二進制文件采用統一的二進制差異算法處理文件的變化。對于文本文件實現差異化存儲，對于二進制文件（圖像、可執行文件）也可以實現差異化存儲。

4）網絡上雙向傳遞差異信息

從服務器到客戶端，或者從客戶端到服務器傳輸被修改的文件，只傳輸文件差異，而不是文件全部內容。

5）支持分支（branch）和標簽（tag）

通過分支與合并，有效支持大項目的并行開發模式。通過標簽管理，準確標識一組文件的版本，有效進行軟件版本管理和必要時的歷史回溯。

6）提供兩種服務模式

一種是C/S模式，在客戶端使用SVN專門設計的協議訪問的SVN服務器。另一種是B/S模式，與Apache集成，在客戶端采用http的擴展協議進行訪問。

7）支持兩種數據存儲方式

SVN支持BDB數據庫和FSFS文件系統。

1.2搭建配置管理環境

SVN通常采用C/S架構，在服務器上安裝SVN服務器軟件，建立一個版本庫（Repository），將數據（項目）導入版本庫。在客戶端安裝Tortoise SVN軟件，用戶通過個人密碼登陸SVN服務器開展自己的工作。

2　配置管理的基本概念

2.1配置項

配置項［4］（Configuration Item），簡稱 CI，是配置管理的基本單位，可以分為3種主要類別：計算機程序（源代碼和可執行程序）、文檔和數據。

2.2版本

版本［6］（Version）是標識了的配置項的實例。在軟件開發過程中，配置項的版本隨項目進展不斷變化，隨著內容的修改或更新，配置項會有不同的版本號。

2.3基線（Baseline）

在軟件開發過程中，一個配置項或一組配置項在不同時間點上，通過正式評審進入受控狀態，就是基線［8］。

基線建立之后，該基線的內容被“凍結”，不能隨意修改。基線是下一步開發的出發點。對基線進行修改要按照變更請求的過程處理。作為配置管理的基礎，基線保證了后續開發活動所需信息的穩定性和一致性。

軟件的主要階段基線見表1。

表1　階段基線和相應配置項列表Tab.1 The list of the corresponding configuration items and the phase of the baseline

設計階段的基線，通常以文檔的形式存在。編碼基線和測試基線是開發階段基線，與軟件源代碼緊密相關。

2.4版本庫

版本庫［3，5，7］是軟件開發過程中存放產品數據的存儲空間。邏輯上版本庫可以分為開發庫（動態庫、程序員庫、工作庫）、受控庫（靜態庫、主庫）、產品庫（軟件倉庫）。版本庫實際的物理存儲結構根據軟件項目具體情況來確定。

1）開發庫：在開發過程中的技術文檔、源代碼、可執行代碼和數據。

2）受控庫：修改權限受控的文檔庫和程序庫，包括基線庫和其他軟件產品。

3）產品庫：交付用戶的產品和運行環境。

3　軟件配置管理的相關角色

參與配置管理包括如下人員：項目經理（PM）、系統工程師（SE）、軟件開發人員（DEV）、軟件測試人員、配置管理員（CMO）、持續集成工程師（CIE）、質量保障人員（QA）、資料員。

其中項目經理、質量保障人員、配置管理員、開發代表、測試代表、系統工程師組成產品配置控制委員會（CCB，Change Control Board）。CCB的職責為：建立、更改基線的設置，審核變更申請；定制訪問控制；指導配置管理的各項活動；為項目經理決策提供建議。

4　軟件開發過程中的軟件配置管理和持續集成

軟件開發過程可以分為3個階段：計劃階段、開發階段和維護階段。后兩個階段涉及的活動是相同的，可以合為開發和維護階段。

4.1項目配置管理計劃

對于軟件項目，版本經理要制定項目管理計劃。配置管理員根據項目管理計劃制定配置管理計劃。配置管理計劃的主要內容有：

配置管理的組織機構、配置管理的相關角色和職責、配置管理工具的選擇和配置環境的建立、版本庫的結構、訪問權限設置、配置項的標識、基線的建立、各個里程碑處提交的軟件產品和提交時間、變更控制及配置狀態統計等內容。

4.2權限管理

在版本庫（Repository）的子目錄conf中有3個默認的配置文件分別是svnserve．conf、passwd、authz。svnserve．oonf提供總體上的訪問權限控制。用戶名與密碼放在passwd文件中，項目目錄訪問權限放在authz文件中。通過這3個文件實現用戶權限控制。

配置管理員將用戶分組，對不同的組和不同目錄分別進行授權（不能訪問、只讀、讀/寫），從而保證版本庫的安全。項目開發中的角色權限見表2。

4.3SVN控制管理下的開發工作

開發人員從版本庫下載源代碼，放在本地作為工作副本，在工作副本上進行查看、修改、編譯、運行、測試等操作。

有兩種開發模式：

1）鎖定-修改-解鎖:采用這種模式，版本庫的一個文件被檢出（check out）后，就被鎖定。只有提交（Commit）之后，其他人才能修改該文件。

2）復制-修改-合并（SVN默認的模式）：采用這種模式，開發人員讀取版本庫文件，建立一個私有工作副本——版本庫中文件和目錄的本地映射。用戶并行工作，修改各自的工作副本，最后合并在一起，成為最終的版本。

表2　項目開發中的角色權限Tab.2 The role privileges in the project development

開發人員每天主要工作如下：

1）根據主干庫（trunk）提供的新基線更新（Update）工作副本；

2）檢出（check out）自己需要的文件開始工作。為了提供高質量的源代碼，需要對編寫好的代碼進行單元測試，靜態走碼檢查，沖突處理和本地構建工作。

3）最后將評審過的代碼提交（Commit）到主干庫（trunk）。開發人員提交時，要添加注釋、說明、CR單號、修改原因等，以保證可追溯。

4.4開庫和鎖庫

配置管理員負責每天版本庫的開庫和鎖庫，開庫和鎖庫主要是針對主干庫（trunk）。每天開庫將主干庫（trunk）相應的權限賦予項目組成員。開發人員完成代碼提交后，鎖庫取消項目組成員的相應權限，僅保留配置管理員和持續集成人員的權限。以便持續集成人員完成集成構建工作。

4.5建立編碼基線

配置管理員鎖庫后，持續集成工程師從主干庫（trunk）檢出新提交的代碼，開始構建工作。啟動CI服務器自動執行一系列測試（單元測試、組件測試和一些耗時的代碼審查任務等）；將新提交的代碼與原有版本資源結合快速構建新的版本。若構建成功，可以獲得最新Build版本，建立新的編碼基線，通過電子郵件通知項目經理和開發人員。若構建失敗，不更新基線，通過電子郵件通知項目經理和相關的開發人員對提交的代碼進行修改。

4.6構建內部轉測試版本建立測試基線

通常選擇每周執行一次構建內部轉測試版本。持續集成人員從主干庫（trunk）取得新提交的代碼后，執行全構建任務。啟動CI服務器執行所有的構建工作，包括環境清理、編譯、測試、代碼審查、打包、部署等。全構建任務執行時間較長，有些工作還需要手動執行。生成的版本放在Tag中并標記版本號，提交轉測試流程。測試經理組織進行版本驗證；測試人員進行各種測試，包括功能測試、性能測試等。測試中發現問題，知會項目經理和開發人員及時處理。完成內部轉測試版本測試，就建立了新的測試基線，同時也建立了新的編碼基線，和每日構建建立的基線相比內部轉測試版本建立的基線等級要高一些。

4.7變更管理

變更管理是對變更請求（Change Request，簡稱CR）進行分類、追蹤和管理的過程。變更通常有兩種類型：功能變更和錯誤修補變更。

4.7.1變更請求的分類

在軟件研發過程中會遇到4類變更請求：需求變更、計劃變更、設計變更和工程變更。

對于這4類變更請求，在不同的階段，分別由不同的CCB團體負責決策處理。

4.7.2變更管理流程

在項目開發過程中，配置項的變更要遵循一定的變更機制，經過嚴格的審核才能進行。以上提到的4類變更請求，都有一個通用的變更管理流程，變更管理流程如圖1所示。

圖1　變更管理流程Fig.1　The process of change management

主要由以下4個步驟組成：

1）提交變更申請：在申請中詳細描述：變更的范圍、原因和依據；變更的優先級；變更的影響；建議的變更方案和替換方案。

2）變更評估：CCB收到變更請求之后，對請求進行評估和分析，識別和評估受影響的所有配置項，必要時邀請相關人員參與評審。

3）變更的審批：若接受的變更請求，確定修改方案、修改人、修改版本、修改時間、驗證方式和驗證人。在項目經理的指導下，由配置管理員負責授權。

4）變更實現：配置項修改人執行變更并驗證；由CCB指定的驗證人對變更進行驗證。驗證通過之后，合格的配置項合入受控庫中；然后關閉變更請求并發布。

4.8配置狀態發布

配置狀態發布是建立與維護配置項的記錄；為相關人員提供準確的配置信息；通過記錄和報告變更請求的狀態，為產品的質量、進度、趨勢等跟蹤提供數據。

配置狀態發布的主要內容包括：

配置項狀態，基線發布情況，版本發布情況，變更管理情況，版本庫和權限管理情況。

4.9版本管理

一個產品可以有多個版本，包括內部轉測試版本和對外發布版本。

4.9.1版本管理流程

版本管理的過程如下：

1）項目經理制定版本計劃，包括內部轉測試版本和對外發布版本。

2）開發人員和資料員完成源代碼開發和文檔編寫。3）持續集成工程師每周完成內部轉測試版本構建。4）提交轉測試流程，測試經理組織進行版本測試和驗證。

5）開發活動完成之后，配置管理員準備最終的產品版本、產品文檔、版本光盤包等；提供給測試經理，組織進行最后的版本測試和驗證；

6）測試和驗證通過后，項目經理組織各領域的代表評審，確認版本符合發布要求。

7）進入版本發布流程，版本最終傳遞給客戶。版本管理流程如圖2所示。

圖2　版本管理流程Fig．2　The Process of version management

4.9.2配置管理的移交

配置管理員需要完成以下工作：

1）整理、歸檔數據、代碼（包括可執行文件）和文檔；

2）歸檔或刪除項目版本庫；

3）移交產品版本庫。

5　基于SVN配置管理的持續集成

現在軟件開發通常采用持續集成（CI）［2，5，7］技術，一次構建通常可能包含編譯、測試、審查和部署，以及其他一些事情。本節以ICP-CI服務器為例介紹持續集成。

5.1持續集成系統架構

持續集成包括以下基本要素：開發人員、版本庫、CI服務器、構建工具和反饋機制。持續集成步驟如下：

1）開發人員向版本庫提交代碼。

2）CI服務器輪詢版本庫中的變更，自動檢查動態庫的變化。

3）鎖庫后，下載代碼到CI服務器。

4）設定時間區間，定時自動完成集成構建工作。

5）CI服務器通過電子郵件向項目經理和開發人員反饋構建信息。

5.2部署ICP-CI服務器

1）根據軟件項目的代碼規模、編譯環境、編譯工具選擇CI服務器的CPU、內存等硬件配置和操作系統。一套CI服務器系統可以同時承擔多個軟件產品的持續集成工作。2）ICP-CI服務器系統有兩種部署形式，單機式和分布式。單機式：由一臺CI服務器完成持續集成工作，用于代碼量小于百萬行的開發團隊。

分布式：CI系統由一臺主控服務器和多臺代理服務器組成，主控服務器將持續集成任務下發到各個代理服務器，任務完成之后將任務結果和日志文件發回到主控服務器。

在 Windows環境下主控服務器部署工具為 ICP-CIWindows-Master，代 理 服 務 器 部 署 工 具 為 ICP-CIWindows-Agent。在 Linux環境下主控服務器部署工具為ICP-CI-Linux-Master，代理服務器部署工具為 ICP-CILinux-Agent。主控服務器和代理服務器可以選擇不同的操作系統，通常選擇主控服務器為Windows環境。

3）ICP-CI工具安裝需要解壓安裝包。對于Windows環境下的主控服務器，需要進入 ICP-CI-Windows-Master下的master目錄，執行批處理文件啟動MYSQL數據庫之后，啟動ICP-CI的網頁版頁面。對于代理服務器ICP-CIWindows-Agent和ICP-CI-Linux-Agent需 要 將ICP-CIWindows-Master的服務器IP地址配置到agent目錄下conf文件夾中相應的配置文件中，再執行批處理腳本啟動代理服務器的CI進程。

5.3安裝SVN客戶端

CI服務器需要安裝SVN客戶端命令行工具和圖形工具TSVN。對于windows環境安裝客戶端工具之后，可以選擇安裝支持中文操作的軟件包。

5.4搭建構建工程

打開ICP-CI網頁的頁面，創建軟件產品的構建工程，使用ANT腳本完成出包腳本。構建工程創建成功之后，分別配置更新代碼、靜態檢查、進程編譯、出包、用例測試等步驟。

1）SVN鎖庫之后，通過SVN的更新命令“svn update”更新CI服務器中的代碼。

2）配置產品靜態檢查，產品使用C/C++來編碼，通常采用Pclint作為靜態檢查工具：產品代碼使用java語言，通常采用findbugs和checkstyle作為靜態檢查工具。

3）配置各模塊的編譯腳本和編譯類型，編譯工作為下一步的出包生成進程文件。

4）配置出包的ANT腳本，生成版本包，將版本包部署到相應的目錄下。

5）完成測試用例任務的配置，對版本包進行自動化測試，完成版本包的初步測試。

6　典型案例

某公司的有一個中型軟件開發項目。采用的SVN版本是1．6．16，SVN命令行工具是subversion-1．6．16，SVN圖形工具是TortoiseSVN-1．6．16。持續集成軟件為ICP-CI，主控服務器操作系統為WINDOWS 2003 Server、代理服務器操作系統為Suse Linux 10 x86-64。持續集成服務器共8臺，1臺主控服務器和7臺代理服務器。采用Linux環境下的shell腳本和ANT腳本編程完成持續集成構建工作。工作實踐表明采用基于SVN的配置管理和持續集成有助于管理人員及時了解工作進度和解決存在的問題。

7　結束語

長期的工作實踐表明配置管理在軟件開發過程中占有重要的地位。采用基于SVN的配置管理和持續集成，可以減少開發過程中隱藏BUG的風險，給項目的管理提供良好好的保障。應用軟件的配置管理工作做好了，可以提高軟件的質量，提高工作效率，降低開發成本，從而推動軟件產業的健康發展。

［1］董越．未雨綢繆—理解軟件配置管理［M］．2版．北京：電子工業出版社，2012．

［2］高平，周磊．版本控制系統—Subversion技術及其在軟件開發庫的應用［J］．航空電子技術，2013（1）：24-28．

［3］Paul M．Duvall，Steve Matyas，Andrew Glover．持續集成軟件質量改進和風險降低之道 ［M］．北京：電子工業出版社，2012．

［4］周念．基于SVN的軟件配置管理的應用研究［D］．武漢：武漢理工大學，2013．

［5］相玉娟．基于變更管理的持續集成研究與應用［D］．安徽：合肥工業大學，2009．

［6］Stefan Kung，Lubbe Onken，Simon Large．Tortoise SVN Versionl 1．5．2［M］．Karl Fogel．2005．

［7］Ben Collins-Sussman，Brian W．Fitzpatrick，C．Michael Pilato．Version Control with Subversion For Subversion 1．5［M］．Karl Fogel，2005．

［8］賀自軍．基于SVN的統一協作平臺設計與實現［D］．北京：北京郵電大學，2009．

［9］徐志．工業用戶無功補償優化管理軟件［J］．供用電，2013 （2）:81-85．

［10］黃家棟，陳永業．基于綜合集成賦權法的輸電線路風險評估［J］．陜西電力，2015（9）:70-75．

［11］劉艷陽．配電網無功補償配置原則優化研究［J］．陜西電力，2015（9）:57-61．

［12］李軍軍，黃有方，許波桅．道路修整與應急車輛路徑的集成優化［J］．工業儀表與自動化裝置，2013（5）:8-12．

［13］鮑麗紅．一種高校綜合信息系統集成平臺數據管理方案［J］．工業儀表與自動化裝置，2015（3）:73-75．

The software configuration management and the continuous integration based on SVN

JIANG Wen，LIU Li-kang
（School of Telecommunication Engineering，Xidian University，Xi’an710071，China）

The SVN is a widely used configuration management tool，which is suitable for small and medium-sized software team．This article describes the characteristics of SVN，introduces the basic concept of configuration management and related role；detailed introduced the software configuration management based on SVN and continuous integration，including rights management，the development work under control of SVN，sets up the coding baseline，builds the internal test version，changes management，version management，and other content；Finally introduces a typical case．Practice shows that this management method is helpful to improve the quality of software，is convenient for project managers understand the work progress and timely solve the problems．

version control；configuration management；branch；label；baseline；continuous integration

TP311．56

A

1674－6236（2016）02-0001-05

2015-06-07稿件編號：201506074

國家部委基礎科研計劃：國防預研基金項目（A1120110007）

姜 文（1986—），女，陜西西安人，碩士研究生，工程師。研究方向：圖像處理與分析，文字信息分析處理，數據庫應用和軟件工程。