工程型軟件項目的配置管理實例-資料下載頁

　　

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