軟體配置管理原理
流程中引入配置管理者角色用于管理配置變更
什麼是配置
工具的引入能夠幫助配置管理者自動化處理，工具應該具備下面的特征：
Ø維護一個檔案庫
Ø建立和存放檔案的多個版本
Ø提供權限鎖定的機制
Ø能夠辨別一組檔案的版本
Ø從配置庫中提取/找回檔案的版本
概念
一套應用技術上和管理上的指導和監督的方法。
用來：
識别和記錄配置項的功能特征和實體特征
控制這些特征的變更
記錄和執行變更的處理和執行的狀态
以及驗證其是否符合特定的需求。
簡單講，配置管理就是通過對在軟體生命周期的不同的時間點上的軟體配置進行辨別，并對這些被辨別的軟體配置項的更改進行系統控制，進而達到保證軟體産品的 完整性和可溯性的過程。
CMMI中的配置管理
CMMI 2級（可重複級/受管理級）
建立了基本的項目管理過程來跟蹤費用、進度和功能特性。制定了必要的過程紀律，能重複早先 類似應用項目取得的成功經驗。
CMMI的5級定義
初始級
可重複級
已定義級
已管理級
優化級
常用術語
常用術語
配置
在技術文檔中明确說明并最終組成軟體産品的功能或實體屬性。
包括即将受控的所有産品特性，及其内容及相關文檔，軟體版本，變更文檔，軟體運作的支援數 據，以及其他一切保證軟體一緻性的組成要素。
配置項
配置項是一組軟體功能或者實體屬性的組合，在配置管理過程中，配置項被作為一個單一的實體對待。
一個系統包括的配置項的數目是一個與設計密切相關的問題。
| 配置項 | 分類 |
|---|---|
| 合同類文檔 | 建議書、使用者意向書、使用者需求、工作任務書、合同 |
| 計劃類文檔 | 包括各類項目相關計劃，比如項目過程手冊、項目計劃，配置管理計劃等 |
| 工程類文檔 | 包括需求規格文檔、測試計劃（含測試用例）、設計文檔、需求跟蹤矩陣等 |
| 程式代碼 | 所有開發的源代碼，包括各類支援資料，二進制檔案 |
| 第三方程式代碼 | 由供應商提供的源代碼，并接受供應商的維護 |
| 工具 | 支援軟體開發、建立、維護的工具管理，比如語言開發工具，編譯工具，測試工具，配 置管理工具等 |
| 使用者文檔 | 包括使用者手冊，安裝指南等 |
| 運作環境 | 包含系統運作環境的相關内容，比如系統運作平台，環境設定要求等 |
基線
基線就是配置項在其生命周期的不同時間點上通過評審而進入正式受控的一種狀态，而這個過程被稱為“基線化” 。每一個基線都是其下一步開發的基準。
基線具有以下屬性：
•通過正式的評審過程建立
•基線存在于配置庫中，基線的變更由變更控制委員會（CCB-Change Control Board）控制
•基線是進一步開發和修改的基準
版本和版本辨別
版本是表示一個配置項具有一組定義的功能的一種辨別。
随着功能的增加，修改或删除，配置項的版本随之演變。
版本以版本号進行辨別。
| 号碼 | 釋出類型 | 典型描述 |
|---|---|---|
| XX | 主版本号 | 增加了一個大的特性－可能導緻與原先版本不相容 |
| YY | 次版本号 | 增加了一個小的特性－保持與原先版本相容 |
| ZZ | 維護版本号 | 可以包含一些更改，并且包含自上一次版本釋出以後所有的更新檔。一般地，這個版本要 根據保證和/或支援/維護協定主動送出給所有的使用者 |
| PP | 更新檔版本号 | 包含對客戶或測試組發現和報告的一個或多個問題的解決。此版本隻釋出給報告問題的 客戶或測試組。解決一次問題釋出一個更新檔版本給報告問題的客戶或測試組。更新檔也可 能隻是一種優化 |
主幹與分支
為何需要分支：
團隊協作的本質是分頭工作并且互相配合。
分支可實作并行工作，多頭前進，最後彙合，減少等待和阻塞。
分支可保證團隊人員之間适當隔離，不可長期隔離。
分支也可保證團隊人員之間适當共享。
配置庫
配置管理活動需要在特定的資料庫中完成，這個特定的資料庫被稱為軟體配置庫 。
從廣義上講，軟體配置庫可以包括開發庫，受控庫和産品庫。
從狹義上講，軟體配置庫專指受控庫 。
常用工具
代碼相關
svn、git
文檔相關
wiki
建構相關
make、ant、maven、gradle
Bug相關
jira、禅道、bugfree、Bugzilla
持續內建相關
Jenkins、Bamboo、GitLab CI、Circle CI
環境部署相關
puppet
文檔相關
wiki
建構相關
make、ant、maven、gradle
Bug相關
jira、禅道、bugfree、Bugzilla
持續內建相關
Jenkins、Bamboo、GitLab CI、Circle CI
環境部署相關
puppet