配置管理的概念
配置管理是通過對在軟體生命周期的不同的時間點上的軟體配置進行標識，并對這些被標識的軟體配置項的更改進行系統控制，從而達到保證軟體產品的完整性和可溯性的程序，
配置項
配置項是一組軟體功能或者物理屬性的組合，在配置管理程序中，配置項被作為一個單一的物體對待，一個系統包括的配置項的數目是一個與設計密切相關的問題，
配置項分類
常見的配置項分類如下：
-
合同類檔案：建議書、用戶意向書、用戶需求、作業任務書、合同等
-
計劃類檔案：包括各類專案相關計劃，比如專案程序手冊，專案計劃，配置管理計劃等，
-
工程類檔案：包括需求規格檔案、測驗計劃、測驗用例等設計檔案等
-
程式代碼：所有開發的源代碼，包括各類支持資料，二進制檔案
-
第三方程式代碼：有供應商提供的源代碼，并接受供應商的維護
-
工具：支持軟體開發、簡歷、維護的工具管理，比如語言開發工具，編譯工具，測驗工具，配置管理工具等，
-
用戶檔案：包括用戶手冊，安裝指南等
-
運行環境：包含系統運行環境的相關內容，比如系統運行平臺，環境設定要求等，
基線的概念
在配置管理系統中，基線就是配置項在其生命周期的不同時間點上通過評審而進入正式受控的一種狀態，而這個程序被稱為“基線化”，每一個基線都是其下一步開發的基準，基線具有以下屬性：
1、通過正式的評審程序建立，
2、基線存在于配置庫中，基線的變更由變更控制委員會（CCB-Change Control Board）控制，
3、基線是進一步開發和修改的基準，
版本的概念
版本是表示一個配置項具有一組定義的功能的一種標識，隨著功能的增加，修改或洗掉，配置項的版本隨之演變，版本以版本號進行標識，
版本的命名
以我之前接觸到的華為的版本命名規范簡單介紹一下，當然這個不是一個統一的標準，僅供參考，我記得當時所在的部門好像是采用VxxxRxxxCxxxBxxx的格式去命名版本號，
配置管理角色介紹
-
專案經理(PM)
-
配置管理員（CMO）
-
軟體開發工程師(SDE)
-
軟體測驗工程師(STE)
-
質量保證人員(QA)
-
變更控制委員會（CCB)
這里的話，主要介紹一下這個CMO和CCB，
CMO的話，可以理解為跟部分運維的作業有點類似，亦或者說是跟CI工程師的作業也有類似的地方，他們主要在公司負責給分配一些配置倉庫的權限，代碼發布流程中相關檔案的歸檔等，比如每次提交發版申請的時候，就需要附帶上部署包和對應的部署檔案，測驗報告等，歸檔到某個目錄，一旦提交申請，開發人員就沒有權限再對目錄中的內容進行修改，
相信大家在日常作業中，經常遇到過專案做到一半，需求發生變更了，導致專案延期，在小公司，一套標準的流程是很難執行下來的，很多時候往往考慮到時間成本、人力成本等，都沒有采用標準的流程，但是，久而久之，也會暴露出很多因為流程不規范而引發的問題，CCB的成立，主要用來評估專案程序中的變更及范圍和影響的評估，
在專案開始時，由專案負責人根據專案的情況確定CCB，也可以根據更改請求的情況事件驅動地召集CCB會議，如有必要，可以設立不同級別的CCB，他們具有不同的授權，對不同層次的變更申請進行控制，根據修改的影響范圍，CCB召開相應的評估會議，并邀請相關人員參加，一般專案里面有需求變更，肯定會有知會大家，專案級別的CCB設立可能比較少，更多的可能是QA團隊的人在公司層面整體設立CCB小組，跟進各專案程序質量，
基線變更流程
為什么要了解這些配置相關的東西呢？
作為一個測驗人員，尤其是作為一個剛接觸這行，甚至可能還沒入行的人員，除了對測驗的崗位和職責劃分要清楚之外，還需要了解公司的崗位劃分，專案的流程等資訊，對其他崗位的大致職責也要有一個簡單的了解，這些崗位都有可能是你在入職之后的作業中有可能需要去打交道的，要避免到時候別人一跟你說找哪個哪個崗位的人，然后你聽著一臉懵逼，初學者在求職的時候，容易被刷掉的一個點主要也是在于專案細節，通過很多旁敲側擊的提問，就可以了解到你到專案的熟悉程度，有沒有真的參與過專案的測驗作業，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/298162.html
標籤：其他
上一篇：重新認識HTML（一）別來無恙