如何做大規模軟體的組態管理

一、前言
    對於一個軟體企業，開發出滿足使用者需求的、高品質的軟體產品是其追求的目標，而實現這一目標的關鍵是建立起一個穩定、可控、可重用的軟體開發過程。軟體企業要想永葆競爭優勢就必須不斷地改進它的軟體開發

過程，而要進行軟體開發流程改善就需要有明確的、量化的對現狀的分析和對未來的預期，這些資料來源於對軟體過程的度量，而進行度量的前提和基礎就是軟體組態管理。所以，軟體組態管理工作是以整個軟體過程的改進為目標，是為軟體專案管理和軟體工程的其他領域打好基礎，以便於穩步推進整個軟體企業的能力成熟度等級。而做好軟體組態管理是邁向軟體開發正常化管理的第一步。
    對於中小型軟體開發，軟體組態管理的作用不是很明顯，但對大型軟體開發，由於開發人員眾多，程式量大，系統複雜，軟體組態管理至關重要。
   軟體組態管理對於軟體開發管理是如此重要，它的主要思想和具體內容在於版本控制。版本控制是軟體組態管理的核心思想之一，是指對軟體開發過程中各種程式碼、設定檔及說明文檔等檔案變更的管理。版本控制最主要的功能就是追蹤檔案的變更。它將什麼時候、什麼人更改了檔案的什麼內容等資訊忠實地記錄下來。每一次檔案的改變，檔案的版本號碼都將增加。除了記錄版本變更外，版本控制的另一個重要功能是並行開發。軟體開發往往是多人協同作戰，版本控制可以有效地解決版本的同步以及不同開發人員之間的開發通訊問題，提高協同開發的效率。並行開發中最常見的不同版本軟體的Bug修正問題，就可以通過版本控制中分支與合并的方法有效地解決。

二、大型軟體系統
   大型一體化系統軟體是為了滿足石油勘探開發對地震資料處理與解釋日益增長的需要，而開發的大型處理、解釋一體化系統，該系統由系統平台和應用系統組成，系統平台包括資料平台、互動架構平台、通用顯示工具、可視化顯示平台。在這個平台上構建處理系統、解釋系統和一體化應用系統。專案計劃在兩年內完成，預計程式行數400萬以上、開發人員200餘人。
    經驗表明，軟體規模越大生產率越低。而且隨著軟體規模增大，軟體開發成功率也越低，在我們國家，軟體業還沒有脫離手工作坊的方式。如此大規模的軟體開發，已往手工作坊式的管理方式要改變，軟體組態管理要創新。與其他的一些軟體工程活動不一樣，軟體組態管理的對象——（軟體）配置項，它們不僅是大量人力物力投入的結晶，更是開發經驗的積累，是軟體組織最寶貴的財富。
軟體組態管理貫穿於軟體開發活動的始終，覆蓋了開發活動的各個環節，它的重要作用之一就是要全面的管理儲存各個配置項，監控各配置項的狀態，並向專案經理及項目長提交配置報告。組態管理工作更強調工具的支援，缺乏良好的組態管理工具的話，要做好組態管理的實施會非常困難。軟體組態管理是一項十分繁瑣的工作，同時又和整個軟體的開發活動緊密地聯絡在一起，為使軟體開發能夠始終處於受控之中，就必須建立一套體現軟體工程特點的組態管理體系，並依據體系要求選用軟體組態管理工具。

三、軟體組態管理工具
    Firefly是Hansky公司軟體開發管理套件中的重要組件。Firefly可以對大型軟體開發的程式碼和相關文檔進行管理，具有以下突出的特點：
1、本地工作區（Local Workspace）
    Local Workspace儲存從伺服器上下載的一個分支的下的檔案，開發人員在工作時首先要從伺服器上將最新修改的專案檔下載到本地工作區，然後才能對專案檔進行編輯、編譯、調試等工作。有了Local Workspace，可以保持本地的工作檔案和伺服器上的工作檔案的同步。同時，還可以比較本地工作區檔案與伺服器檔案的不同，在每次下載和上傳時不必將所有的專案檔都傳輸一遍，從而提高了工作的效率。
2、標籤（Label）
    Label採用索引技術提高了操作效率，通過下載Lable的功能為編譯、測試提供了便利。
3、兩種開發模式
    Firefly支援並行/串列兩種開發模式，並且提供嚮導來檢驗和解決檔案的衝突，使得團隊的開發快速、便捷而且高效。
4、分支
    在Firefly中可以方便的建立項目的分支，可以在主分支上建立分支，也可以在次分支上建立分支，還可以在Label的基礎上建立分支；建立分支的時候可以選擇父分支的一部分檔案。
在開發主分支的同時有可能同時開發修正Bug的分支，當主分支的開發工作告一階段後，通常會把Bug修正分支合并到主分支上去，如：

    這種建立和管理項目分支和記錄分支間父子關係的功能，避免了由於兩方歸併所造成的混亂問題，為軟體產品的多個版本的同時開發提供了強有力的支援。
4、變更集
    Firefly將每一次工作區的檢入都視作一個變更集，每一個變更集都作為項目分支的曆史被儲存下來，管理員可以通過WEB介面方便的查詢分支的曆史。
5、原子事務
    利用原子事務的概念，將一個包含多個檔案改變的入庫操作作為一個事務（Transaction）來對待，全部檔案的提交只有成功或者不成功兩種情況，沒有中間狀態（如一部分成功提交，而另一部分提交失敗的狀態）。這樣能夠處理一些操作過程中的異常情況，比如提交過程中網路中斷等，保證軟體系統的一致性，防止其他開發人員取到錯誤的代碼而編譯、運行失敗。　　
6、本地記錄
    通過Delta操作支援本地版本的記錄。在某一工作區中，修改了一個檔案，然後通Delta操作，可以在本地記錄下一個新的版本。提交到伺服器上後，其他人也可以訪問這一版本。
7、許可權控制
    Firefly採取了類似於NTFS的許可權控制體系，不僅能夠控制項目分支一級的許可權，還可以深入到目錄/檔案一級進行許可權設定，檔案的許可權預設從目錄繼承，還可以手工對特定檔案的許可權進行調整；並且可以細分許可權的等級。這種許可權體系可以保證項目所涉及到的開發工作都處於受控的狀態下，從而保障項目不受幹擾，能夠順利開發。

四、建立組態管理體系
1、管理層次
    依據組態管理系統功能特性，結合我們實際情況和需要，建立自己的管理體系。以往，我們已經成功地開發了其他大中型軟體，但組態管理體系很不完善，一些主要配置項（原始碼和程式文檔）是靠手工管理，由於人員流動性大，又沒有統一的組態管理體系，開發活動不能受到有效控制，不能形成團隊財富的積累。有人對組態管理是什麼都不清楚，對組態管理系統的使用在思想上不容易接受，認為使用組態管理系統進行程式版本控制使開發活動受到了限制，給開發增加了工作量。特別是這次超大規模軟體系統的開發，時間緊，任務重，如果組態管理系統使用不當影響項目進度或造成來源程式丟失，會給開發帶來巨大損失，後果不堪設想。
為此，從管理層次和系統整合兩個方面考慮，選擇了降低管理風險方案，首先採用了兩層管理層次（圖1 二層管理層次圖）。
2、存放庫建立
    依據兩層管理員模式，組態管理和版本控制主要在項目級和子項目級組態管理員中使用。從一體化系統的結構來說，儘管該系統龐大，包括許多子系統，但是，最終要整合一個系統，而且管理員模式決定了版本控制是在項目開發到一定階段，形成初步系統模型時納入版本控制。因此在Firefly伺服器上建立一個程式碼庫，用來儲存初步整合的原始碼。使用這樣的庫結構有利於對配置項的統一管理和控制，同時也能提高編譯和發布的效率。　

3、使用權限設定
    建立一個代碼存放庫，是為了便於統一管理，但是如何讓開發人員根據任務分工的不同而獲得對相應配置項（原始碼）的操作許可，而對於其他原始碼不能操作。為此，利用Firefly提供的檔案級存取權限設定，對不同目錄進行使用者權限設定，只有對該目錄具有讀寫權限的使用者才能對其進行操作，為子系統組態管理員授權一個檔案目錄，２使用權限設定圖中src/ap目錄授權給smq使用者。

????????
圖2 使用權限設定

4、分支的劃分
·　整合分支　　
    為了系統整合測試需要，建立整合分支，並對該分支進行了不同子項目的許可權控制，各子項目必須將開發成果納入到該分支，凡是對納入到該分支的配置項進行的任何變更，都必須首先從該分支獲得，變更後再上傳到該分支。軟體的整合測試工作在這一分支中進行。項目級組態管理員擁有對該整合分支的管理和讀寫權限，子項目級組態管理員只有對指定的目錄有讀寫權限。（圖3分支圖）
·　主幹分支
    主幹分支對應的是整個軟體開發組織的發布分支。各個子項目在現階段的任務完成後，將發行就緒的版本歸併到該分支上，由該分支產生髮布版本，對每次的發布基準和相關資料，以該分支上的版本為準。該分支的管理工作由項目級組態管理員負責。（圖4分支及標籤）　　
上面定義的2類（分支）由組態管理員統一管理，根據各開發階段的實際情況定製相應的版本選取規則，來保證開發活動的正常運作。
比如，軟體已經發布了1.0版本，開發小組在為該軟體添加新的功能，進行中2.0版本的開發。而此時，如果Release 1.0中發現了Bug必須修正，我們就必須從Release 1.0中建立bugfix分支，進行必要的修正後，發布修正版Release 1.1，而這個版本的發布與2.0版本的開發沒有直接關係。當2.0版本測試結束後，要與1.0版本中bugfix分支合并，從而發布2.0的版本。在這個並行開發過程中，建立分支和分支的合并起了非常重要的作用。

圖3 分支
?
圖4 分支及標籤

·　產品基準
    當一個開發裡程碑結束，或有重大事件發生時，利用組態管理系統提供的標籤功能，對整合分支和主幹分支進行標記，該標記作為產品基準，可以按標記進行版本發布和再現（圖4分支及標籤）。
·　與分支對應的本地工作區
    把相關配置項納入集中的存放庫、為不同目的建立了不同分支後，按照初始設定的管理層次，子項目級組態管理員遵照“檢出/檢入”的工作模式對配置項進行修改，就要為每位子項目級組態管理員設定本地工作區，對所授權的目錄進行的任何變更都要在本地工作區進行。
·　開發工作區
    開發人員根據項目要求在自己的私人工作區中對配置項進行修改和測試活動，私人工作區可以是CVS版本控制軟體工作空間或其他，自己的修改活動不會受到他人的影響，也不會影響到其他開發人員，修改和測試後的配置項提交給子系統組態管理員，由子項目級組態管理員上傳到整合分支。
五、逐步完善分支建立方式
1、依據開發需要，建立平台分支
    由管理層次決定的分支是一個主分支一個整合分支，但隨著開發活動的深入，系統平台開發和應用開發之間出現互相牽制問題，平台程式變更後在沒有與應用程式聯調之前，會影響到應用程式的開發，嚴重時會使應用程式開發工作無法正常進行，為了尋找原因，有時需要花上一兩天時間，影響了開發進度。鑒於這種情況，新建立了系統平台分支，系統平檯子項目組在該分支開發整合，待測試通過並與應用聯調後再利用分支歸併功能，將程式歸併到整合分支，既達到了程式控制的目的，又不影響開發進度，有效提高了開發效率。這一分支方式說明了通過科學管理可以出效率。
2、為了方便管理，建立連結分支
    平台分支和整合分支應用一段時間後，又出現了新的問題，平台的變更，需要通過應用程式進行測試。但是，系統平台分支上的應用程式不能時時更新，除非將整合分支的應用合并到平台分支，這樣給管理帶來許多麻煩，為瞭解決該問題，利用FireflyV3.0版本中提供的連結功能，在系統分支上建立了連結，連結到整合分支的應用部分，這樣，平台分支可以隨時得到應用系統變更的檔案，大大方便了測試版本的製作。（圖5連結點）。
    開發過程中系統分支和應用整合分支以及連結的應用，使平台開發和應用開發可以有序進行，消除了平台變更對應用開發帶來的影響，促進了開發進度，有效地控制了平台和應用的變更，為開發階段版本管理和控制起到了很好的作用。

圖5 連結點

3、為發布產品，啟用主幹分支
    在項目開發階段基本結束，進入產品發布階段後，除了建立產品基準外，啟用了主幹分支為發布分支，整合分支上測試通過的程式，及時合并到發布分支製作發布版本。在產品發布初期，使用者和試生產發現問題比較多，程式變更頻繁，每周要整合一個新版本，為了標示不同時間編譯的版本，除了版本號碼之外，附加了BuildNumber來標示，4所示的標籤。

六、依據測試階段，整合軟體版本
    從軟體工程化和保證產品品質出發，軟體測試採用三級測試方式：單元測試、整合測試和生產性測試（試生產），由於項目開發時間緊，不能一級測試結束，再開始下一級測試，而均採用滾動開發測試方式進行，多數情況下是同時進行，這給版本控制和整合帶來很大困難，為此，建立了三種Integration Environment。三個版本的版本控制和整合是通過分支、測試基準、分支合并來完成。
1、單元測試
    單元測試由開發人員在相對穩定的系統開發平台上進行，其中，相對穩定的系統平台需要整合一個系統平台版本。
2、整合測試
    整合測試是將各個子系統組成一個可運行系統的重要階段。由於一體化軟體是系統平台與應用系統幾乎同時開發的項目，系統平台內部、應用系統內部，以及平台與應用之間的組裝都需在整合測試階段完成。
3、生產測試
    生產測試要求整合測試後比較穩定的版本，該版本利用標籤進行標示。
4、版本回溯
    在測試中，經常出現新修改的程式版本有問題，需要回溯到上一個版本，這是，使用組態管理系統提供的版本管理功能非常方便地回到任意一個程式版本。

七、完善和改進組態管理體系
    在兩年來的開發管理和版本控制中，有成功也有教訓，最初使用組態管理系統時，對其功能和使用方式不熟悉，出現了許多問題，對項目開發產生了一些影響，一度出現了放棄組態管理工具的念頭，最終在各方面人員的支援下，使得組態管理系統得以繼續在管理中發揮作用。
1、改進管理層次
    在系統整合階段使用組態管理系統進資料列版本設定，解決了許多問題，促進了開發效率，為項目按期完成提供了有利保證。但是，在管理層次中，開發人員的開發活動沒有納入統一的控制之中，這種方式容易造成修改的版本不是最終版本問題。
針對上述現象和兩年來的使用經驗，在項目開發進入一個新的階段時（開發2.0版本），將版本控制範圍擴大到每一位開發人員，使每個開發人員的開發活動始終處於版本控制之中，管理層次6所示。
2、增加子分支
    為達到上述目的，子系統組態管理員也應該是分支管理員，為此，在整合分支下建立應用子系統的子分支，子分支分別由子系統組態管理員管理並設定使用者權限，進行子系統整合，然後再歸併到整合分支。
3、本地工作區
    每位開發人員的工作空間都使用與組態管理系統相連的本地工作區，開發活動始終處於受控之中。

八、經驗與體會
    在版本控制和管理方面的經驗主要體現以下幾個方面：
1、建立以“版本控制”為中心的大規模軟體組態管理體系
    對於一體化系統這樣前所未有的超大規模、且開發週期僅兩年的軟體開發項目，如何保證軟體開發在有序與受控方式下進行，是項目成功開發要解決的關鍵問題。
    首先，要制定一套體現項目特點的軟體組態管理體系，才能使開發處於受控之中。據此，項目組決定引進組態管理系統進行組態管理和版本控制，這也是首次在如此大規模的軟體項目中使用組態管理系統。由於是初次使用，基於過去軟體開發的經驗，結合本項目的特點和軟體組態管理的現狀，制定了適合本項目的版本控制階層（見圖1），分支策略和許可權控制。
2、依據軟體開發的需要，建立組態管理體系
    在項目開發過程中，依據每個開發階段的具體運作實踐，對版本控制階層和分支策略進行完善與實用化改進。組態管理體系的建立，使開發機構的開發模式逐步邁入工程化開發管理的新時期。

九、結束語
    通過兩年項目開發實踐，許多開發人員對版本控制的概念有了新的認識，從最初的抵觸情緒到後來主動要求要使用組態管理系統，基本形成了軟體工程化的開發氛圍。
    兩年來，在項目長、各級子項目長和項目部主管領導的支援下，一體化系統組態管理體系得到了有史以來的發展和完善，管理員和開發人員的觀念得到了轉變，初步形成了一套適合大規模應用軟體項目開發的版本控制與管理體系，積累了比較豐富的技術與管理經驗。組態管理體系的建立，增強了Team Dev對大規模軟體開發的版本控制能力，為Team Dev的可持續發展奠定了技術基礎，積累了軟體財富。
有效地記錄並控制軟體開發過程產品版本演化進程，是搞好過程式控制制的基礎。軟體組態管理體系的有效實施，使軟體開發活動合理有序，為進一步搞好軟體專案管理和開發管理奠定了基礎。建立開發、測試受控庫，確定受控基準，對來源程式、運行環境進行嚴格的版本管理與變更控制，確保項目過程產品的一致性、正確性和安全性，有效地降低了開發風險，縮短了產品的開發週期。因此，組態管理體系作為開發管理的主要過程之一，對處理、解釋一體化系統的開發成功起到了不可替代的作用。