一、軟件配置管理原理
配置管理的常用術語有四個：配置，配置項，基線，版本標識
1、配置和配置管理的概念
配置：配置是在技術文檔中明確說明並最終組成軟件產品的功能或物理屬性，因此，“配置”包括了最終組成軟件產品所有的文檔，軟件版本，變更文檔，軟件運行的支持數據，相對於硬件類配置，軟件產品的”配置“包括更多的內容並具有易變性。
配置管理：配置管理就是通過對在軟件生命周期的不同的時間點上所產生的文件進行標識，並對這些被標識的文件的更改進行系統控制，從而達到保證軟件產品的完整性和可溯性。
2、配置項的概念
為了方便對“配置”進行管理，“配置”經常被划分為各類配置項，這類划分是進行軟件配置管理的基礎和前提。配置項是一組軟件功能或者物理屬性的組合，在配置管理過程中，配置項被作為一個單一的實體對待，一個系統包括的配置項的數目是一個與設計密切相關的問題。
3、基線的概念
在配置管理系統中，基線就是配置項在其生命周期的不同時間點上通過評審而進入正式受控的一種狀態，而這個過程被稱為“基線化”，每一個基線都是其下一步開發的基准。所以基線具有以下屬性。
（1）通過正式的評審過程建立。
（2）基線存在於配置庫中，基線的變更由變更控制委員會（CCB-Change Control Border）控制。
（3）基線是進一步開發和修改的基准。
4、版本和版本標識
版本：版本是表示一個配置項具有一組定義的功能的一種標識。隨着功能的增加，修改或刪除，配置項的版本隨之演變，版本以版本號進行標識。
版本號：命名規則為了維護軟件項目，我們提出了對版本進行管理控制的要求，而對於用戶來說，版本直接體現在版本號的命名上。
1、版本號的三種命名方式：
版本號由二到四個部分組成。主版本號和子版本號是必須要有的，修正版本號和編譯版本號可以自己選擇
（1）GNU風格的版本號命名格式
主版本號 . 子版本號 [ .修正版本號 [ .編譯版本號] ]
例如： 5.0.0 build-1234 主版本號 子版本號 修正版本號 編譯版本號
（2）Windows風格的版本號命名格式
主版本號 . 子版本號 [ 修正版本號 [ .編譯版本號] ]
例如： 1.12 主版本號 子版本號 修正版本號
（3）. Net Framework風格的版本號命名格式
主版本號 . 子版本號 [ .編譯版本號 [.修正版本號 ] ]
2、版本號的管理策略
（1）項目初版本時，版本號可以為0.1或0.1.0，當然也可以為1.0或者1.0.0。
（2）當項目在進行局部修改或者bug修正時，主版本號和子版本號都不變，修正版本號加1。
（3）當項目在原有的基礎上增加了部分功能時，主版本號不變，子版本號加1，修正版本號復位為0（可以被忽略掉）。
（4）當項目進行了重大修改或者局部修改累積較多，而導致項目整體發生全局變化時，主版本號加1。
（5）編譯版本號一般是編譯器在編譯的時候自動生成的，我們只定義其格式，並不進行人為控制。
5、配置庫
配置管理活動需要在特定的數據庫中完成，這個特定的數據庫被稱為軟件配置庫。
將軟件配置項匯聚在一起，形成了配置庫。
從廣義上來講，軟件配置庫可以包括開發庫，受控庫和產品庫，從狹義上講，軟件配置庫專指受控庫。
6、主干和分支
分支的原因：
（1）團隊協作的本質是分頭工作並且相互配合。
（2）分支可實現並行工作，多頭前進，最后匯合，減少等待和阻塞。
（3）分支可保證團隊人員之間適當隔離，不可長期隔離。
（4）分支也可保證團隊人員之間適當共享。
7、版本控制（Subversion工具）
配置管理伴隨着軟件開發的歷史逐步發展，產生的主要原因是管理難度的加大。
（1）軟件復雜度增加。
（2）參與協同作業的人員增加。
（3）工作方式更加國際化。
所以軟件配置流程引入配置管理員CMO（Configuration Management Officer）用於管理變更控制。
工具的出現幫助配置管理員自動化處理，工具應具備如下特性：
（1）維護文件庫。
（2）創建和存放文件的多個版本。
（3）提供鎖定的機制。
（4）標識一組文件的版本。
（5）從配置庫中提取、找回文件的版本。
下面我們就來介紹關於版本控制的軟件工具。
8、版本管理軟件--（Subversion工具）
（1）Subversion（簡稱SVN）的概念
Subversion（簡稱SVN）是近年來崛起的版本管理軟件，它是一個通用系統，可以管理任何類型的文件集。Subversion的版本可以通過網絡訪問，從而使用戶可以在不同的電腦上進行操作，從某種程度上來說，允許用戶在各自的空間里修改和管理同一組數據可以促進團隊協作。
（2）SVN基本結構
SVN服務器分為Windows和Linux版本，有兩種運行方式：獨立的SVN服務器和借助Apache。
SVN的版本庫（Repository），也叫項目倉庫，就是位於服務器統一管理和儲存數據的地方，對Repository最常用的操作就是簽入（commit/check-in）和簽出（check-out），就像出庫和出庫一樣。
（3）悲觀鎖VSS（串行）和樂觀鎖SVN（並行）
悲觀鎖：
VSS是基於“鎖定-編輯-解鎖”模式的，這個模式，有一個弊端，就是當其他人在編輯相關文件的時候，此單元處於鎖定狀態，其他人如果想編輯這個單元文件的話，只能處於等待狀態，
樂觀鎖：
SVN是基於“修改-沖突-合並”的一個模式，也就是說多個人可以同時簽出一個單元文件，編輯然后提交，如果多個人都修改了同一文件的某一行的話，就會發生沖突，手工解決沖突。
（4）SVN的應用。
SVN中常用的提交、簽出、更新命令是什么？
提交：commit；
簽出：checkout；
更新：update。
*在SVN的配置管理模式下，如果兩個人同時修改同一個文件的同一行，遇到了沖突可以如何解決？
Merge合並。
兩人訪問同一服務器：checkout 到本地 。 A先提交 。
B修改提交，提交時會提示out of date ,需要update ；update之后修改文件內容，刪除不需要的內容，保存。
*在SVN的配置管理模式下，兩個人各自修改了不同的行。
兩人訪問同一服務器：checkout 到本地 。 A先提交 。
提交之后會出現一個新的版本，這時B需要update，然后修改提交。
二、軟件配置管理組織
1、配置管理角色介紹
（1）項目經理（PM項目負責人）
*制定項目的配置計划。
*制定CMO。
*建立項目的CCB。
*保證為項目提供合適的配置管理工具。
（2）配置管理員（CMO）、
*建立和管理配置項
*保存變更申請。
*基線化配置項。
*生成並發布配置狀態發布表。
*將基線化的文檔和計划分發給所有相關人員。
*管理配置庫的訪問權限。
*增加/刪除配置項（僅在收到已獲批准的請求時）。
*備份/恢復和歸檔配置庫。
*想項目成員提供配置管理工具使用的指導。
（3）軟件開發工程師（SWE）
*開發工程師將自己創建的與開發相關的配置項（比如需求規格說明書、概要設計、詳細設計、代碼等配置項）加入配置庫中。
*開發工程師根據變更請求，對配置項進行check-out、修改、check-in的操作。比如測試人員在提交bug之后，開發人員應該在CMO授權之后，對相應的配置項（源文件）check-out、修改、check-in。
（4）軟件測試工程師（STE）
*測試工程師將自己創建的與測試相關的配置項（比如軟件測試計划、軟件測試方案、軟件測試用例、軟件測試日報、軟件測試報告等）加入配置庫中。
*測試工程師根據變更請求，對測試相關的配置項進行check-out、修改、check-in操作。
*獲取被測試的已發布的軟件版本。
（5）質量保證人員（QA）
*基線審計。
*評審並批准配置管理計划。
*驗證配置庫的備份。
（6）變更控制委員會（CCB）
*評估和批准對配置項的更改。
*確保批准后的更改的實施。
三、配置管理的過程
根據IEEE的定義，配置管理的五大活動是指：
1、配置計划。
2、配置標識。
3、配置控制。
4、配置狀態發布。
5、配置審計。