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