軟體配置管理基礎

軟體配置管理

軟體配置管理 （Software Configuration Management, SCM）

問題引出

IEEE 定義

A discipline applying technical and administrative direction and surveillance to identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements.

一套應用技術上和管理上的指導和監督的方法，用來：識别和記錄配置項的功能特征和實體特征；控制這些特征的變更；記錄和報告變更的處理和執行的狀态，以及驗證起是否符合特定的需求。

有那麼一類管理

軟體配置管理，是關于軟體資産的管理。

軟體 = 源代碼 + 文檔。

源代碼、設計文檔、可以運作的程式等在軟體研發過程中産生的有價值的東西，都是軟體資産。

圖書管理 VS 軟體管理

1. 圖書管理的事圖書資産，軟體配置管理管理的是軟體資産。其實這兩種管的都是資訊資産。
2. 圖書管理，需要把圖書進行分類，以便檢索；需要将圖書存放在合适的地方，以便存取。還要防止蟲吃鼠咬。軟體配置管理也類似，需要把軟體資産放在合适的目錄結構裡。防止丢失或者錯亂。
3. 在圖書館，要記錄圖書的借閱情況，為了保證圖書不丢失；在軟體配置管理中也類似，需要記錄哪位程式員借出了哪個檔案，什麼時候還。如果程式員修改了它，還需要記錄下來這些修改。
4. 圖書需要更新，軟體也需要更新。

為什麼是配置管理

1. 汽車配置：底盤（傳動系、轉向系、制動系和行駛系）、發動機、車身、電氣裝置
2. 電腦組態：主機闆（記憶體、CPU、顯示卡）、硬碟、機箱、顯示器、外設
3. 手機配置：螢幕、CPU、GPU、記憶體、閃存、主機闆、按鍵
4. 軟體配置：代碼、文檔、安裝程式、引用類庫、資源檔案

從機器的視角，每個零件都有型号、編号。很容易想到，應該有某種清單或者文檔來表明各個零部件型号群組成關系（Bill of Material, BOM）。當配置有變動的時候，要跟新這樣的清單。而且這樣的變動不能随随便便的，應該先讓總工程師準許，做相應的測試。

從軟體的視角，軟體也是配置起來的。各個源檔案、源代碼和正确的文檔搭配起來，編譯産生正确的可以運作的程式。

另外軟體配置管理更有自己的特點：

1.軟體更容易發生變化，是向前演進的。

2.軟體的相關性（耦合）更高，一旦需要改動，通常不是隻更改一個檔案。

其他的比喻

• 結繩記事
• 攀岩岩釘
• 保險櫃
• 腳印
• ……

最終定義

是一種應用于整個軟體工程過程的辨別、組織和控制修改的圍繞軟體資産的管理技術。

軟體配置管理，又稱軟體形态管理、或軟體建構管理，簡稱軟體形管。界定軟體的組成項目，對每個項目的變更進行管控（版本控制），并維護不同項目之間的版本關聯，以使軟體在開發過程中任一時間的内容都可以被追溯，包括某幾個具有重要意義的數個組合。

在軟體建立時變更是不可避免的，而變更加劇了項目中軟體開發者之間的混亂。SCM活動的目标就是為了辨別變更、控制變更、確定變更正确實作并向其他有關人員報告變更。從某種角度講，SCM是一種辨別、組織和控制修改的技術，目的是使錯誤降為最小并最有效地提高生産效率。

從流程角度看，軟體配置管理是整個軟體開發生命周期中一個非常核心的管理過程。配置管理實際貫穿了從需求分析、架構設計、項目管理、開發、內建建構、測試以及上線的全過程。這一過程不僅涉及宏觀的項目進度控制、配置管理規範及計劃、多地點開發規劃等，也包括更細粒度的分支模型、建構及內建方式、變更處理流程，還包括微觀的與開發人員直接相關的版本控制、差異比較和歸并等。

Version Control-版本控制

Change Control-變更控制

Process Support-過程支援

關鍵活動包括：配置項、版本庫管理、版本控制、變更控制、狀态報告、配置審計等。

術語解釋

配置

“配置”是在技術文檔中明确說明并最終組成軟體産品的功能或實體屬性。是以“配置”包括了即将受控的所有産品特性，及其内容及相關文檔，軟體版本，變更文檔，軟體運作的支援資料，以及其他一切保證軟體一緻性的組成要素。

配置項

為了友善對“配置”進行管理，“配置”經常被劃分為各類配置項，這類劃分是進行軟體配置管理的基礎和前提。 配置項是一組軟體功能或者實體屬性的組合，在配置管理過程中，配置項被作為一個單一的實體對待。 一個系統包括的配置項的數目是一個與設計密切相關的問題。

• 文檔：一篇文檔就是一個配置項
• 代碼：推薦将整個項目組的所有代碼當做一個配置項。如果項目組内不同子產品之間的進度相差很大的時候，将每一個子產品的代碼劃分為一個配置項更加友善管理。

基線

在配置管理系統中，基線就是配置項在其生命周期的不同時間點上通過評審而進入正式受控的一種狀态，而這個過程被稱為“基線化”。

每一個基線都是其下一步開發的基準。

基線具有以下屬性：

• 通過正式的評審過程建立。
• 基線存在于配置庫中，基線的變更由變更控制委員會（CCB-Change Control Board）控制。
• 基線是進一步開發和修改的基準。

版本

版本是表示一個配置項具有一組定義的功能的一種辨別。随着功能的增加，修改或删除，配置項的版本随之演變。

版本以版本号進行辨別。

• 版本号 Version Number：為簡略的表達特定版本的目的和意義，為友善區分不同的版本，我們需要版本号這個概念。又稱作版本辨別。
• 版本庫：也叫存儲庫，Repository。在版本庫裡，存儲源代碼的各個版本。當然存儲的是不同版本見有差異的部分，增量存儲。
• 簽入：檢入，check in. 代碼修改完了以後，需要告知版本控制工具，将新的代碼儲存到版本庫中。
• 簽出：檢出，chekc out。代碼修改前，需要先告知版本控制工具，講版本庫中的代碼複制到本地。

玄妙的學院派

配置計劃

配置管理計劃是開展所有配置管理活動的基礎。

計劃中應該明确以下要素：

• 配置管理人員的組織和職責
• 配置項的命名規則
• 配置管理工具以及配置庫結構
• 辨別的配置項和位置
• 權限配置設定和管理方法
• 配置庫備份的周期、方法
• 變更控制的流程和操作方法
• 版本釋出的計劃和政策
• 基線審計計劃
• 內建政策
• 軟體配置管理的場景

配置辨別 Configuration Identification

是配置管理的一個組成部分，包括：選擇産品的配置項、為他們制定唯一的辨別，并在技術文檔中記錄其功能和實體的特性。

配置辨別是對軟體配置進行管理的前提和基礎。配置辨別包括了軟體配置項的選擇、劃分和對配置項的功能實體屬性進行描述的過程。

每個配置項都必需被唯一地辨別，這個唯一的辨別被用于與其它配置項進行區分，跟蹤和報告該配置項的狀态。一般地，每個配置項被賦予一個辨別符。

• 文檔：對所有文檔而言，檔案名就作為配置項的命名
• 代碼：使用“項目名-子產品名＋代碼”或者“項目名＋代碼”的方式進行命名
• 工具：以工具本身的名稱命名

定義配置項的版本

單個配置項在每一次修改後都會發生變化，為了辨別配置項在兩次修改之間的不同，需要對配置項的版本進行辨別。

配置項版本命名原則

配置項的版本辨別建議采用的形式為：xx.yy的十進制辨別符，其中xx起始為“1”，yy起始為“0”。

所有數字均是阿拉伯數字，并且單調遞增。如果發生了重大的修改，xx遞增；如果隻有小修改，遞增yy。

已基線化

成為基線的配置項是指已完成該配置項的稽核、準許和簽發并且成為建立或修改其他配置項的輸入。

受管理和受控的

受管理和受控的配置項是指已送出稽核，但還沒有準許通過的配置項。

配置控制 Configuration Control

是配置管理的一個組成部分，包含評估、協調、準許/拒絕、實施對配置項的變更。

這發生在正式的配置辨別之後。

配置控制包括配置項在完成基線化後所産生的變更的評估、協調、準許、駁回以及實作過程。

• 變更請求的管理
• 變更的協調工作

在項目開始時，由項目負責人根據項目的情況确定變更控制委員會（Change Control Board, CCB），并記錄在配置管理計劃中。CCB組長也可以根據更改請求的情況事件驅動地召集CCB會議。CCB也可以批量處理更改請求或采用定期的方式進行處理。

如有必要，可以設立不同級别的CCB，他們具有不同的授權，對不同層次的變更申請進行控制根據修改的影響範圍，CCB召開相應的評估會議，并邀請相關人員參加

配置狀态報告 Configuration Status Report

是配置管理的一個組成部分，記錄和報告用來有效管理配置所需要的必要資訊。這些資訊包括一個已準許的配置辨別清單，變更請求目前的處理狀态，以及已準許的變更的實作情況。

配置狀态報告是跟蹤對軟體的更改的過程，它保證對正在進行和已完成的變更進行記錄、監視并通報給項目組和相關組成員。

一旦配置項基線化後，應該通知項目組， 内容應該包括基線化配置項的名稱以及位置。另外應該周期或事件驅動地将更新後的配置狀态發給項目組成員以及相關組，以確定配置項的狀态能被相關人員所了解，根據需要一周或者兩周釋出一次（配置管理者的工作）

• 版本庫相關的資訊：名字、存儲位置、編号、管理者、主要用途描述
• 版本庫中産品的相關資訊
• 檔案相關的資訊
• 變更請求、基線、釋出、版本庫的備份等

配置審計 Configuration Audit

執行審計以驗證配置項符合特定的标準或需求

對配置管理的獨立的查檢過程，确認受控軟體配置項滿足需求并就緒。

• 功能審計：配置項的變更控制是否和配置管理計劃中的描述相一緻
• 實體審計：配置項的完整性、正确性, 一緻性和可跟蹤性

軟體配置管理的組織

角色

• 項目經理 PM: Project Manager
  • 制定和修改項目的組織結構和配置管理政策；
  • 準許、釋出配置管理計劃；
  • 決定項目起始基線和開發裡程碑；
  • 接受并審閱配置控制委員會的報告。
• 變更控制委員會 CCB: Change Control Board
  • 負責指導和控制配置管理的各項具體活動的進行，為項目經理的決策提供建議。其具體職責為以下幾項：
    • 定制開發子系統；
    • 定制通路控制；
    • 制定常用政策；
    • 建立、更改基線的設定，稽核變更申請；
    • 根據配置管理者的報告決定相應的對策。
• 軟體配置工程師 CMO: Configuration Management Officer
  • 根據配置管理計劃執行各項管理任務，定期向CCB送出報告，并列席CCB的例會。其具體職責為以下幾項：
    • 軟體配置管理工具的日常管理與維護；
    • 送出配置管理計劃；
    • 各配置項的管理與維護；
    • 執行版本控制和變更控制方案；
    • 完成配置審計并送出報告；
    • 對開發人員進行相關的教育訓練；
    • 識别軟體開發過程中存在的問題并拟就解決方案。
• 系統內建工程師 SIO: System Integration Engineer
  • 系統內建員負責生成和管理項目的内部和外部釋出版本，其具體職責為以下幾項：
    • 內建修改；
    • 建構系統；
    • 完成對版本的日常維護；
    • 建立外部釋出版本。
• 軟體開發工程師 DEV: Software Engineer
• 軟體測試工程師 QA: QA Engineer / Tester

制定配置管理流程

配置管理實施的一個重要階段，主要目的是根據項目開發的需要，制定相應的配置管理流程，以更好地支援開發，主要活動包括：

• 定制并行開發政策。合理的并行開發政策應該具有以下特點：協調項目的複雜性和需求，統一建立分支類型和中繼資料，為開發過程中的變更內建制定有效的規範，适時反映開發過程中方法和需求的變化。
• 釋出版本管理。軟體開發過程中的一個關鍵活動是提取工件的相關版本，以形成軟體系統的階段版本或釋出版本，一般将其稱為穩定基線。一個穩定基線代表新開發活動的開始，而一系列定制良好的活動之後又會産生一個新的穩定基線。有效地利用此項功能，在項目開發過程中可以至始至終管理、跟蹤部件版本間的關聯。

軟體配置管理 in CMMI

能力成熟度內建模型(Capability Maturity Model Integration, CMMI)是由美國卡耐基·梅隆大學的軟體工程研究所組織開發，并于2002年釋出的一種規範、實用的途徑來管理軟體過程的模型。CMMI通過指導軟體開發人員的活動來改進軟體過程，以達到軟體過程可複用性、可定量管理、可有效控制的目的。

軟體配置管理是CMMI可重複級的一個關鍵過程域(Key Process Area，KPA)，其目的是在整個項目的軟體生命周期中，保持軟體産品的完整性和可追蹤性，這包含了對改變的控制和所有能影響到改變的軟體因素的管理。作為過程實作、過程優化的一部分，配置管理是實作軟體過程的基本保證，它還是基于重用的軟體開發的管理手段，是以成為軟體過程管理的核心。CMMI模型清晰地描述了SCM，并說明了SCM 的目的和所要達到的目标，具體描述了某級成熟度下軟體過程在該方面所應達到的一組目标和實作這些目标的一組關鍵實踐(Key Pradice)。這些關鍵實踐被劃分為5類，分别為完成該組目标所需的承諾、執行能力、執行的活動、度量分析以及驗證．使企業在實施軟體配置管理時能知道到底要做什麼，團隊的配置管理現狀如何評估，在哪些方面還可以進行改進等問題能得到具體的答案。

在CMMI中，對包括軟體配置管理在内的配置管理工作，從如下角度進行了劃分：

• 建立基線

首先，識别配置項；接着，建立配置管理系統，用來存放配置項；最後，通過評審或測試後，由配置項組成基線，作為未來開發的基礎。

• 建立并控制變更

要追蹤變更請求，這包括新功能、功能增強，也包括缺陷。要評估它們，配置設定給合适的人去處理它們，還要檢查以確定它們确實被處理了。要控制對配置項的變更，如果要改它，需要合适的人同意。改好後，要适當檢查，才能入庫。

• 建立完整性

首先，要對配置管理活動做足夠的記錄。比如，對配置項的修訂曆史，對變更請求的狀态轉換過程，對不同基線的差異，等等；其次，要進行配置審計。确定配置項的内容是否合适，并出現在合适的地方，确定基線的内容正确。

• 制度化已管理過程

在一個軟體研發項目中做配置管理，首先要建立配置管理計劃，然後確定有足夠的資源，包括工具、環境，也包括人員。在配置管理系統運轉過程中，要适當監控。

• 制度化已定義過程

要形成可以指導現在和未來多個軟體研發項目的配置管理過程規範。這樣的規範不是一成不變的。要手機相關的資訊、資料和回報。并基于此進行軟體配置管理的持續的改進。

配置管理的實踐

• 版本控制
  • 古老做法：檔案夾目錄共享，建立公共存儲區
  • 現代做法一：檔案加鎖、修改、送出更新、解鎖
  • 現代做法二：并行修改。由版本控制工具記錄每個人修改前的版本和修改後的版本，然後再合并。
  • 即使隻有一個程式員：程式員需要備份、復原源代碼、分支代碼。
  • 多個程式員：多個程式員可能需要修改同一份源代碼、需要等待測試團隊的測試等。
  • 測試人員：需要統一需求文檔、測試用例、測試計劃等文檔。
• 代碼建構
  • 建構：編譯、連結和打安裝包用來測試和釋出的過程。
  • 及早和經常的內建，持續內建 Continuous Integration，必須充分借助于自動化工具的程度。
  • 建構的日志必須記錄和儲存
  • 每日建構：每天将最新的源代碼進行編譯，打包并通過冒煙測試。
• 持續內建
  • 系統內建：簡稱內建，System Integration，其基本的使命，就是把産品的各個部分捏合在一起，并且保證産品作為整體是可以轉的。并且運轉沒有問題。
  • 內建不一定發生在各個子產品都開發完以後，而開始于設計階段。
  • 作為改進，內建可以逐漸進行。每完成一個子產品，就加入到整體環境中來，發現問題并解決。
  • 。
• 并行開發
  • 版本标簽：在目前分支通過标簽的方式整體記錄版本。
  • 版本分支：通過分支産生并行的版本進行新功能開發或者長期持續維護
  • 适當隔離與适當共享
• 管理文檔
  • 文檔和源代碼：源代碼是人編寫出來，給機器運作；文檔是給人閱讀。
  • 文檔必須帶有版本号和作者
  • 對修改有簡單的描述，版本需要有最終狀态
  • 趨勢：Wiki 來源于夏威夷語(wee kee wee kee)，中文是“快點快點”的意思。修改和展示都是基于網絡的，在浏覽器中完成。
• 跟蹤缺陷
  • 軟體資産的改動會不可避免的産生缺陷，或者潛在的bug。
  • 通過缺陷跟蹤系統，以及bug的狀态轉換，使得bug得以修複。
  • 分析統計缺陷相關資料，尤其注意漏測率。
• 管理變更
  • 比缺陷更廣闊的的話題，是變更請求。
  • 功能增強。
  • 在瀑布模型中管理變更

主流工具

• Borland StarTeam

StarTeam是Borland公司的配置管理工具，是收費工具。

通過連接配接多個應用程式生命周期管理 (ALM) 庫，優化您的軟體開發生命周期 (SDLC)。通過跟蹤對源代碼、缺陷和功能的變更，擷取對團隊、項目和工具的控制。

StarTeam 的軟體配置管理功能可用于在整個 軟體開發生命周期SDLC 中管理和跟蹤源代碼變更，包括變更請求、缺陷、任務、需求使用者案例和讨論。它提供了跨各種工具和存儲庫的更改。StarTeam 的軟體配置管理功能同時适用于集中和異地軟體開發團隊，同時還可在您的所有軟體資産中保持可見性和可追溯性，可用作您的單一事實來源。

• IBM Rational ClearCase

Rational ClearCase 作為一款功能強大的軟體配置管理( SCM )工具，在國内已經得到許多企業使用者的認可并被廣泛采納。

IBM Rational ClearCase 通過自動化、內建和最佳經驗簡化了變更過程。ClearCase 幫助您更好地管理變更和資源，控制開發過程中發展演化的一切内容，包括需求、設計模型、源代碼、變更請求以及測試腳本等。

• VSS (Microsoft Visual SourceSafe)

VSS 的全稱為 Visual SourceSafe 。作為 Microsoft Visual Studio 的一名成員，它主要任務就是負責項目檔案的管理，幾乎可以适用任何軟體項目。管理軟體開發中各個不同版本的源代碼和文檔，占用空間小并且友善各個版本代碼和文檔的擷取,對開發小組中對源代碼的通路進行有效的協調。

• TFS (Microsoft Team Foundation Server)

  TFS作為VSS的替代者，具有十分強大的功能。

  1. 面向整個團隊的協作工具

     Team Foundation Server 提供了一系列可與您的現有 IDE 或編輯器結合使用的協作工具，以便您的團隊可以有效地處理各種形态和規模的軟體項目。

  2. 面向靈活團隊的工具

     看闆、Scrum、儀表闆

     根據自身情況靈活處理。通過積壓工作和可自定義的看闆，捕獲和跟蹤工作情況，并确定工作優先級。 工作項直接連結到代碼以確定透明性，并可用于生成豐富的儀表闆，友善您輕松生成報告。

  3. 持續內建

     生成、驗證、部署

     使用持續內建 (CI) 生成盡早捕獲品質問題，此類生成可以在代碼發生變化後自動編譯和測試您的應用程式。 使用持續傳遞自動部署應用程式或網站，這些應用程式或網站通過測試或對釋出管道進行模組化以比對您現有的釋出流程。

• CVS (Concurrent Versions System)

CVS是一個C/S系統，是一個常用的代碼版本控制軟體。主要在開源軟體管理中使用。與它相類似的代碼版本控制軟體有subversion。多個開發人員通過一個中心版本控制系統來記錄檔案版本，進而達到保證檔案同步的目的。CVS版本控制系統是一種GNU軟體包，主要用于在多人開發環境下的源碼的維護

• SVN (Subversion)

Subversion是一個自由，開源的版本控制系統。在Subversion管理下，檔案和目錄可以超越時空。Subversion将檔案存放在中心版本庫裡。這個版本庫很像一個普通的檔案伺服器，不同的是，它可以記錄每一次檔案和目錄的修改情況。這樣就可以籍此将資料恢複到以前的版本，并可以檢視資料的更改細節。正因為如此，許多人将版本控制系統當作一種神奇的“時間機器”。

• Git
  1. Git是一款免費、開源的分布式版本控制系統，用于靈活高效地處理任何或小或大的項目。
  2. Git的讀音為/gɪt/。
  3. Git是一個開源的分布式版本控制系統，用以有效、高速的處理從很小到非常大的項目版本管理。
  4. Git 是 Linus Torvalds 為了幫助管理 Linux 核心開發而開發的一個開放源碼的版本控制軟體。

Torvalds 開始着手開發 Git 是為了作為一種過渡方案來替代 BitKeeper，後者之前一直是 Linux 核心開發人員在全球使用的主要源代碼工具。開放源碼社群中的有些人覺得 BitKeeper 的許可證并不适合開放源碼社群的工作，是以 Torvalds 決定着手研究許可證更為靈活的版本控制系統。盡管最初 Git 的開發是為了輔助 Linux 核心開發的過程，但是我們已經發現在很多其他自由軟體項目中也使用了 Git。

參考：

https://www.jianshu.com/p/f8d81680a7cf