我們所說的配置項變更流程主要是針對配置項發生變化的控制，在我們的項目中分為兩個部分，首先是對配置項新建、檢入（CheckIn）和檢出（CheckOut）的規定；其次是對入庫的文件類型和大小的規定：
新建、檢入、檢出及破壞
1、 新建：即Add，除特殊情況外，一般不規定由誰來新建（只要有權限即可），但盡量指定每個project只有一人負責新建。
2、 檢入：即check in，檢入頻率規定如下：
i. 在代碼編寫前，至少每周一次
ii. 代碼編寫階段，至少每天一次
iii. 測試階段以后，根據代碼、文檔的變動，只要當天有變動就要檢入一次。
iv. 為配合檢查、備份工作，需在檢查備份周期前全部check in (不保持check out)并退出登錄。詳見“檢查及備份”部分
3、 檢出：即check out。原則上只對要修改的文檔方可檢出。
4、 破壞（Destroy）：一般情況不可以破壞文件、目錄。
5、 如果是誤操作，則可在一天內提交管理員處
6、 如果超過一天，則需要由項目經理同意，且管理員破壞前要備份。
7、 各階段環境職責
|
環境 |
階段 |
負責人 |
職責 |
| 公司內部 | 編碼前 | 開發人員 |
每周及需要評審前check in工作產品（包括版本發布說明）到VSS上 |
| 開發組長 | 每周 | ||
| SCM人員 | 每周統計 | ||
| 編碼 | 開發人員 |
每天check in工作產品（包括版本發布說明）到vss上 | |
| 開發組長 | 每周檢查 | ||
| 經理及組長 | 抽查及走讀 | ||
| SCM人員 | 每周統計，檢查代碼風格 | ||
| 測試 | 開發人員 |
每天check in工作產品到vss上（如當天沒有修改可以不進行check in） 以LABEL形式提交一個新版本給測試，附帶版本發布說明 | |
| 測試人員 | 對測試完成后的程序打LABEL | ||
| 發布后 | 開發人員 | 將新版本check in到vss,打測試LABEL,向測試人員提交申請 | |
| 測試人員 | 對測試完成后的程序打LABEL | ||
| SCM人員 | 對變更做好控制和記錄，并發布 | ||
| 現場開發負責人 | 將發布后的產版本更新至現場，或指定人員進行 | ||
| 公司外部 | 編碼 | 現場開發負責人 |
在無法通過sos連到公司vss的情況下，需要在現場建立配置庫（文件方式或VSS等），做到基本的版本控制和備份。每周至少通過SOS提交一次至公司的VSS庫中。 |
| 現場開發人員 | 每天check in工作產品到現場配置庫（包括版本發布說明）。 | ||
| SCM人員 | 做好督促和監督工作，每周將現場開發負責人提交的現場版本更新到公司配置庫（vss）。 | ||
| 測試 | 現場開發人員 | 每天check in工作產品到現場配置庫（如當天沒有修改可以不進行check in）。 | |
| 如已經回公司則每天check in工作產品到公司配置庫vss（如當天沒有修改可以不進行check in）。 | |||
| 每周通過SOS提交一個新版本給測試，打測試LABEL,附帶版本發布說明(如沒有更新可不提交) | |||
| 對測試完成后的程序打LABEL | |||
| SCM人員 | 做好督促和監督工作 | ||
| 發布后 現場調試 現場維護 | 現場開發負責人 | 在無法通過sos連到公司vss的情況下，需要在現場建立配置庫（文件方式或VSS等），做到基本的版本控制和備份。每周至少通過SOS提交一次至公司的VSS庫中。通過LABEL提交測試版本 | |
| 現場開發人員 | 對修改后的版本通過SOS check in 新版本到vss,打測試LABEL,向測試人員提交申請（由修改至提交測試人員不應超過三天） | ||
| 測試人員 | 對測試完成后的程序打LABEL | ||
| SCM人員 | 對變更做好控制和記錄，并發布 | ||
| 做好督促和監督現場提交更新版本到vss。 |
1、 文件名及目錄規定：以英文名字命名
2、 文件大小規定：最大不超過20M
3、 允許類型：
4、 表2.1中提至的文檔類
5、 代碼及腳本類及為配合編譯需要的類庫等
6、 以下類型不允許存放在VSS庫中：
7、 備份數據
8、 安裝程序、打包程序（zip\rar）
9、 超過20M以上的非代碼類及開發文檔類文件
10、 對于特殊情況或不確定情況，需向配置管理人員咨詢后再加入
11、 對于不允許存放類型的配置類文件，可與配置管理員聯絡，隨件附《說明清單》，以文件型式保存于服務器。
配置項發布
配置項發布是指配置項進行到一定的階段（例如，里程碑階段），需要對外發布時的規則。在我們的項目中，配置項發布是通過標簽，即LABEL，來實現的。
|
階段 |
觸發事件 |
操作人 |
標簽類型 |
打標簽的級別 |
| 單元測試 | 單元測試完成，可以提交集成測試 | 開發人員 | FOR_TEST | 模塊級 |
| 集成測試 | 集成測試完成，不通過（如通過進入系統測試階段） | 測試人員 |
TESTED | 模塊級 |
| BUG修改完成，可以提交測試 | 開發人員 | FOR_TEST | 模塊級 | |
| 集成測試通過，可以提交系統測試 | 測試負責人 | TESTED | 模塊級 | |
| 系統測試 | 系統測試完成后，不通過，（如通過進入系統測試階段） | 測試負責人 | TESTED |
項目級 |
| BUG修改完成，可以提交測試 | 開發人員 | FOR_TEST | 項目級 | |
| 系統測試通過 | 測試負責人 | TESTED | 項目級 | |
| 驗收測試 | 驗收前的版本，可發布到現場安裝 | 配置管理員 | LOAD |
項目級 |
| 驗收后的版本，可發布的正式版本 | 配置管理員 | LOAD | 項目級 | |
| 現場維護 | 修改BUG后提交測試 | 維護工程師 | FOR_TEST | 模塊級/項目級/文件級 |
| 測試通過與否 | 測試人員 | TESTED | 模塊級/項目級/文件級 |
基線確立與變更
基線的確定在上一部分中已經說到過，我們的項目基線分為兩類，一類是作為里程碑和其他工作依賴的基線（例如需求文檔、設計文檔等），另一類是開發過程中有必要保留的一種狀態（例如代碼過程中某個模塊的一個有保留價值的snapshot）。對這兩種不同的基線，其影響的范圍不同，確立和變更方式也不一樣。
我們項目的基線變更控制委員會由客戶代表、產品經理、項目經理以及技術經理組成，對發布的里程碑類基線的變更必須由變更控制委員會確認并由QA進行變更記錄，所有被變更影響的配置項都需要重新同步后再次發布；而對于僅僅作為工作狀態保留的基線，一般只需要建立基線的小組確認更改并在QA進行記錄即可。
檢查與備份
1、 檢查：
根據VSS白皮書建議，要定期檢查數據的正確性。故VSS庫管理員應每周檢查一次，流程如下：
a) 開發人員于每周五下午5:30前check in（(不保持check out)）并退出登錄
b) VSS庫管理人員用analyze工具檢查VSS數據庫，操作如下：
在dos命令行中輸入：analyze –f –d –c –v4 c:\vss\data
其中“c:\vss\data”為vss庫的數據目錄
2、 備份：
a) 每天增量備份，通過windowsNT以上自帶的備份工具進行增量備份，備份以硬盤存放即可。
b) 每周全備份：每周檢查完畢之后，對VSS數據庫進行全備份，建議以光盤介質備份。
配置管理實施后記
應該說，這次我們對項目的配置管理實施是非常成功的，在整個開發過程中，基本沒有出現因為配置管理的問題導致的對開發進度的延誤。當然，在開發過程中也發生了由于需求變化導致基線變更引起開發進度的延遲，不過這不應該算作是配置管理的失誤，因為作為配置管理來說，只能盡量保證基線變更不會導致項目失控。
總結我們這次的配置管理實施工作，除了這幾篇文章中講到的需要注意的問題外，我覺得有一些應該算做是決定實施成敗的關鍵因素：
1、 一個好的執行人員是成功的關鍵；
一個好的執行人員的重要性怎么強調都不過分。所謂的一個好的執行人員應該具備這樣的素質：
a) 對配置管理工作有較為深刻的理解；
b) 對使用的配置管理工具運用熟練；
c) 具有好的溝通能力，能和開發組長、開發人員以及其他干系人溝通；
d) 有好的執行力，對流程的執行能起到監督和推動作用；
e) 耐心細致，很多時候，細節決定了成��；
2、 好的工具能起到事半功倍的效果；
選擇一個合適的配置管理工具絕對是必要的，我們在前面用了一章多的篇幅介紹我們使用的配置管理工具及其方案，事實證明，我們選擇的配置管理工具對我們項目管理實施的效果是決定性的。
3、 在配置管理實施的初期，及時的指導起的作用是巨大的，甚至可以說是成功的主要因素；
對不熟悉配置管理的開發工程師來說，配置管理工作容易在一開始就讓他們產生厭煩情緒，一點點使用上的不方便就會導致開發人員對配置管理的怨言，這個時候，及時的指導就顯得非常重要了，我們在配置管理實施過程中，準備了《VSS操作手冊》、《SOS簡明操作手冊》、《配置管理操作指導書》等手冊，進行了三次的培訓，并在實施過程中隨時解決開發人員在使用配置管理工具中的問題。而且，在實施初期，我們以獎勵為主，在一個月的時間內沒有將配置管理工作作為考核內容。
4、 每周的配置狀態檢查非常重要；
在配置管理基本走上正規后，每周的配置狀態檢查是我們對配置管理執行效果的檢查，一旦發現問題，會作為QA問題報告發出并要求限期改正。如果沒有這個檢查制度，配置管理工作很難持續受控。
〔后記〕
《工程型軟件項目配置管理實例》這幾篇文章是我們在項目的配置管理實施過程中的一些體會，和其他配置管理文章不同的是，這里我們給出的都是馬上就可以應用的實踐步驟。當然，每個公司的環境各有不同，同樣的實踐不可能在每個地方都能產生一樣的效果，只是希望這一系列文章能給大家一些啟發。
時間倉促，文章中有些地方可能還有未能表達清楚的地方，歡迎大家和我探討。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
