【摘要】

我于2005年1月至2006年1月參加了某個知名飲料集團公司的企業(yè)信息系統(tǒng)的開發(fā)工作，該大型集團的業(yè)務(wù)主要涉及到奶制品的進銷存。本人在項目中負責(zé)系統(tǒng)分析，設(shè)計和部分測試與系統(tǒng)實施的工作，本文從配置管理工具的選擇、配置管理流程制定、配置管理庫結(jié)構(gòu)的確定，以及作為配置管理工作的推動者如何推動這項工作等方面仔細描述。本人參與了該項目的系統(tǒng)分析、設(shè)計、測試和實施工作，實現(xiàn)了該系統(tǒng)的庫存管理、供應(yīng)鏈管理、銷售管理和OA等子系統(tǒng)。通過該項目的配置管理和實施，應(yīng)該說，這次我們對項目的配置管理實施是非常成功的，在整個開發(fā)過程中，基本沒有出現(xiàn)因為配置管理的問題導(dǎo)致的對開發(fā)進度的延誤。當(dāng)然，在開發(fā)過程中也發(fā)生了由于需求變化導(dǎo)致基線變更引起開發(fā)進度的延遲，不過這不應(yīng)該算作是配置管理的失誤，因為作為配置管理來說，只能盡量保證基線變更不會導(dǎo)致項目失控。

【正文】

2005年年初，我參加了某個知名飲料集團公司的企業(yè)信息系統(tǒng)的開發(fā)工作，該大型集團的業(yè)務(wù)主要涉及到奶制品的進銷存，該項目的工作量大約是12人年，項目周期約為1年。大部分（90%以上）的開發(fā)工作在前6個月內(nèi)完成，后期的工作主要由維護人員進行系統(tǒng)維護和調(diào)整。在6個月的開發(fā)時間中，前4個月由開發(fā)人員在公司進行開發(fā)，根據(jù)用戶的需求完成設(shè)計，確定系統(tǒng)架構(gòu)并實現(xiàn)整個框架，部分明確的功能以及公用模塊也在這段時間內(nèi)完成；后2個月的時間部分開發(fā)人員在現(xiàn)場，部分開發(fā)人員在公司共同完成后期的開發(fā)工作。整個項目采用的開發(fā)語言是C++、Java、ASP，涉及的平臺包括Solaris和Windows，采用的開發(fā)工具包括Visual Studio和Solaris上的CC。此外，整個項目還使用了一些第三方的平臺，如IBM的MQ等。除用戶需求之外，公司還對項目組提出了代碼復(fù)用方面的要求，開發(fā)人員在開發(fā)過程中必須注意代碼的可重用性。

在項目正式啟動之后，配置管理工作就可以開始了。配置管理工作開始的第一步就是一份配置管理計劃。我認(rèn)為需要在配置管理計劃中明確的內(nèi)容包括：
1、 配置管理軟硬件資源；
2、 配置庫結(jié)構(gòu)；
3、 人員、角色以及配置管理規(guī)范；
4、 基線計劃；
5、 配置庫備份計劃；

配置管理環(huán)境包括軟硬件環(huán)境。具體的資源需求應(yīng)該根據(jù)項目實際情況來確定，一般需要考慮的包括：網(wǎng)絡(luò)環(huán)境、配置管理服務(wù)器的處理能力、空間需求，配置管理軟件的選擇等。配置管理環(huán)境的確定需要綜合考慮各個方面的因素，包括我們采用的開發(fā)工具，開發(fā)方式，開發(fā)人員對配置管理工具的熟悉程度等，其中，開發(fā)人員對配置管理工具的認(rèn)可和熟悉程度常常直接決定配置管理能否正常進行，如果選擇了需要開發(fā)人員花費比較大的精力去熟悉的配置管理軟件，我們就必須花費大量時間來進行培訓(xùn)；同時，配置管理軟件和開發(fā)工具的集成程度也是一個必須考慮的因素，根據(jù)我們的經(jīng)驗，選擇一個和開發(fā)環(huán)境集成緊密的配置管理工具至少可以減少20%花費在Check In/Check Out和配置管理人員保持配置庫完整上的工作量。根據(jù)我們項目的實際情況，我們有如下一些考慮：
根據(jù)歷史經(jīng)驗，一個類似項目的配置庫大小約為3G，考慮到備份等操作對空間的需求，至少應(yīng)該為配置管理庫保留10G以上的空間。為了保證配置管理庫的安全，除了相應(yīng)的備份計劃之外，還可以采用了RAID 0＋1的方式為配置數(shù)據(jù)庫提供更好的可用性保證；考慮到在項目的后期有部分開發(fā)人員會在現(xiàn)場進行開發(fā)，因此在網(wǎng)絡(luò)條件上需要提供對遠程訪問方式的支持；配置管理服務(wù)器的選擇和配置管理軟件的選擇相關(guān)，考慮到目前公司有一臺閑置的PC服務(wù)器，最好能充分利用這臺服務(wù)器；配置管理軟件必須可以以某種方式支持遠程訪問，而且由于我們的開發(fā)平臺涉及Solaris和Windows，配置管理軟件要能夠支持這兩種平臺；考慮到開發(fā)工具方面，配置管理工具要求能和我們選擇的開發(fā)工具進行很好的集成；項目組的開發(fā)人員缺乏使用配置管理工具的經(jīng)驗，有將約30%的開發(fā)人員使用過VSS配置管理工具，但僅限于最基礎(chǔ)的使用，對VSS的Label等功能沒有概念；結(jié)合以上的情況，我們首先考慮配置工具的選擇。

從開發(fā)人員具有的配置管理工具使用經(jīng)驗和配置管理工具使用的難易度方面來說，VSS是最好的選擇，在現(xiàn)有的基礎(chǔ)上只需要對開發(fā)人員進行簡單培訓(xùn)；考慮到和開發(fā)工具的集成，VSS也是一個不錯的選擇。因為VSS簡單易用，在大多數(shù)人眼里，VSS似乎都只是一個玩具，難登大雅之堂，最多能管管自己的代碼，要用團隊開發(fā)中，那似乎是不可能的。剛接觸VSS時，我也是抱著差不多的想法，覺得要用VSS作為一個較大的項目的配置管理工具完全不可能，但隨著對VSS研究的深入，加上在工作中也使用了其它一些配置管理工具，如CVS、ClearCase、CCC harvest等工具，反過來比較，反而覺得VSS有它獨到的地方。不過本項目還要求對遠程接入方式的支持，以及對Solaris平臺的支持，VSS肯定是不能滿足要求的（VSS通過VPN方式應(yīng)該是可以實現(xiàn)對遠程訪問的支持，但VSS的完全共享方式實在是不敢在Internet上使用）。除VSS外，可以選擇的配置管理工具還有CCC Harvest、ClearCase、CVS等，但Harvest和ClearCase使用起來比較復(fù)雜，需要一個專門的配置庫管理員負責(zé)技術(shù)支持，還需要對開發(fā)人員進行較多的培訓(xùn)，另外，Harvest和ClearCase價格不菲；CVS在Unix下使用方便，而且是免費的，但其文本方式的操作界面對于習(xí)慣在Windows平臺上開發(fā)的開發(fā)人員來說使用非常不習(xí)慣（CVS也有windows下的GUI版本，但經(jīng)過我們的試用，在操作習(xí)慣上和我們目前開發(fā)人員習(xí)慣的方式很不相同，較難被接受）。 經(jīng)過在MSDN和Internet上查找，終于找到了一個VSS的增強軟件SOS（Source Offsite），它基于VSS的數(shù)據(jù)庫，可以支持通過TCP/IP方式訪問和操作VSS庫，在Windows、Slolaris和Linux上都提供了客戶端，并且通過傳輸數(shù)據(jù)的壓縮和加密方式，使得文件操作的速度大大加快并增強了系統(tǒng)的安全性。事實證明，VSS＋SOS的組合在我們的整個項目過程中起到了關(guān)鍵的支持作用。我們使用的SOS是3.53的Standard版本。

確定了配置管理工具后，我們使用公司購置的一臺Compaq PC Server作為配置管理的硬件環(huán)境，VSS對硬件配置要求不高；作為一個工作組級別的配置管理工具，在我們的項目中，安裝VSS的配置服務(wù)器是一臺P4 2.2G/512M RAM/30G×4 Disk的HP PC服務(wù)器，這樣的條件下VSS運行已經(jīng)足夠穩(wěn)定和快速，相比起CC和CCC harvest的要求，這部分的投資是很小的；如果再考慮到CC和CCC都運行在Unix平臺上需要的維護費用，當(dāng)然是VSS更加劃算了。

最終確定的方案是安裝該服務(wù)器安裝Windows 2000 Server操作系統(tǒng)，為了保證配置數(shù)據(jù)的安全性，我們采用RAID 0＋1方式，總的可用空間在50G左右；另外為了備份的需要，還為服務(wù)器配置了一個CDR刻錄機。
對于網(wǎng)絡(luò)環(huán)境的選擇，因為公司已有現(xiàn)成的100M局域網(wǎng)，通過一個交換機和路由器連接至Internet，有一個公網(wǎng)的靜態(tài)IP；配置管理服務(wù)器是內(nèi)網(wǎng)的一臺機器，具有一個內(nèi)網(wǎng)IP。為了滿足遠程訪問的需要，我們通過在路由器上設(shè)置端口映射，將SOS需要使用的端口映射到配置管理服務(wù)器上（缺省情況下，SOS使用8888和8890兩個端口）。網(wǎng)絡(luò)拓撲圖如下：

在公司的開發(fā)人員通過局域網(wǎng)使用VSS訪問和操作配置庫，在現(xiàn)場的開發(fā)人員通過Internet接入對配置庫進行訪問和操作。
我制訂了配置庫維護和備份計劃 ，配置庫的維護的備份需要專職的配置庫管理員來負責(zé)。在整個項目中我們采用的配置庫維護策略是根據(jù)Microsoft的Best Practice白皮書建議，包括以下要點：
1、 保持配置數(shù)據(jù)庫的大小不超過5G；Microsoft建議，配置庫的大小在3－5G比較合適，太大的數(shù)據(jù)庫會極大影響VSS的效率；減小配置庫大小的
2、 每周進行VSS數(shù)據(jù)庫的分析（Analysis），發(fā)現(xiàn)問題及時修正；VSS提供了Analysis和Fix工具，由于不合理的Delete等操作，VSS數(shù)據(jù)庫有可能會出現(xiàn)一些Interrupt Data之類的問題，通過定期的每周的分析工作，可以極大減少數(shù)據(jù)庫出現(xiàn)問題的風(fēng)險；
3、 每日進行配置庫的增量備份，每周進行數(shù)據(jù)庫的完全備份；VSS庫的備份可以通過VSS自己的Archive功能或者是操作系統(tǒng)的Backup程序來進行。VSS的Archive功能對VSS中的文件數(shù)據(jù)進行壓縮并保留VSS的所有狀態(tài)，但只能對VSS庫進行完全備份，不能實現(xiàn)增量備份功能。Windows2000 Server提供的Backup實用程序可以對文件進行備份，由于VSS庫就是以文件形勢存在的，因此針對VSS的data目錄進行備份也可以完全達到備份的目的，使用系統(tǒng)備份工具的好處是可以實現(xiàn)增量備份。我們在實際中使用的系統(tǒng)的備份工具，每周五生成的完全備份采用刻錄光盤的方式保存，每天的增量備份數(shù)據(jù)存放在文件服務(wù)器上進行備份。



配置項的命名包括兩個方面的內(nèi)容：
1、配置項標(biāo)識：在我們的項目中，一般使用“項目名_配置類別_配置項特殊標(biāo)識”來命名。配置項命名中的“配置項特殊標(biāo)識”根據(jù)配置類別的不同而不同。比如，對“設(shè)計文檔”，如果細分的話，可以分為“概要設(shè)計”和“詳細設(shè)計”；對“代碼”，可以按照模塊來命名配置項。
2、配置項版本命名：配置項版本命名是針對配置項的版本進行命名，在我們的項目中，配置項版本通過對Project的Label操作來實現(xiàn)，配置項版本的命名需要能清楚標(biāo)識配置項的狀態(tài)。一般說來，配置庫至少包括個人工作區(qū)、受控庫、發(fā)布區(qū)三個部分，在我們的項目中，所有的配置項都保存在一個VSS庫中，對這三個部分的劃分是通過邏輯劃分方式進行的，具體來說，就是通過配置項版本命名來劃分的。因此，我們配置項的版本命名規(guī)定如下：
a) 基線版本：按照基線的狀態(tài)，我們這個項目中的基線有兩個方面：一是作為里程碑的基線；另一個是模塊的階段性成果基線（對工作產(chǎn)品而言），由模塊的負責(zé)人確定。
里程碑基線――對我們的項目來說，采用的是迭代的開發(fā)過程，以一個迭代過程為例，分為需求、概要設(shè)計、詳細設(shè)計、代碼實現(xiàn)、單元測試、集成測試、系統(tǒng)測試七個階段，每個階段都需要產(chǎn)生里程碑。對每個里程碑都有明確的標(biāo)識標(biāo)明當(dāng)前狀態(tài)。
階段性成果基線――階段性成果主要體現(xiàn)在代碼過程中，比如代碼進行到一個階段，開發(fā)組長認(rèn)為代碼的這個狀態(tài)可以保留，就可以確定為一個代碼基線。這種基線一般不需要通過評審等正式手段來確定，但也必須有相應(yīng)的驗證手段；比如在我們的項目中，在代碼階段，確定代碼基線的責(zé)任人是開發(fā)組長，但開發(fā)組長必須保證代碼基線符合一定的條件。
b) 其他版本：除基線版本外，有時候還需要在開發(fā)和維護過程中確定其他版本。例如，產(chǎn)品在測試過程中不斷的問題修復(fù)過程中，可能會有多種反復(fù)，此時需要將每次修改的內(nèi)容作為一個版本。
關(guān)于版本，還有另一個需要注意的問題。一般來說，按照模塊來劃分，每個模塊有自己的版本演進比較合理。首先，一個模塊一般是由一個或兩個開發(fā)人員完成的；其次，一個模塊的功能會比較單一且獨立，在版本的演化過程中便于控制，也不會和其他模塊產(chǎn)生過于復(fù)雜的關(guān)系。而產(chǎn)品的版本則需要由各個模塊的不同版本組成，這個縱橫的關(guān)系需要很好地管理，我們的做法是在VSS庫上用Label來標(biāo)識，同時維護一張描述產(chǎn)品版本和模塊版本關(guān)系的矩陣圖便于追蹤。

在確定了配置項之后，就可以確定配置庫的目錄結(jié)構(gòu)了。配置庫的目錄結(jié)構(gòu)直接關(guān)系到配置管理的工作量和使用的方便性，所以需要根據(jù)自己的需要確定一個合理的結(jié)構(gòu)。
在確定配置管理庫目錄結(jié)構(gòu)的時候，我們曾經(jīng)考慮過兩種產(chǎn)品目錄結(jié)構(gòu)的方式：一種是按照模塊劃分，在模塊下再劃分諸如設(shè)計文檔、代碼等目錄；另一種方式是按照產(chǎn)品類型劃分，例如首先是文檔、代碼，然后在其下按照模塊劃分。這兩種方式都有自己的優(yōu)點，最終我們還是選擇了前一種劃分方式，一方面是考慮便于進行權(quán)限的分配，另一方面是考慮到便于將同一模塊的所有內(nèi)容組織起來進行版本的管理。

角色是配置管理流程的執(zhí)行者和參與者，定義明確的角色有利于實現(xiàn)明確的授權(quán)和明晰的流程，雖然在實際中可能多個角色由一個人擔(dān)任，但還是應(yīng)該保留角色的定義。
我們所說的配置項變更流程主要是針對配置項發(fā)生變化的控制，在我們的項目中分為兩個部分，首先是對配置項新建、檢入（CheckIn）和檢出（CheckOut）的規(guī)定；其次是對入庫的文件類型和大小的規(guī)定：新建、檢入、檢出及破壞
1、 新建：即Add，除特殊情況外，一般不規(guī)定由誰來新建（只要有權(quán)限即可），但盡量指定每個project只有一人負責(zé)新建。
2、 檢入：即check in，檢入頻率規(guī)定如下：
i. 在代碼編寫前，至少每周一次
ii. 代碼編寫階段，至少每天一次
iii. 測試階段以后，根據(jù)代碼、文檔的變動，只要當(dāng)天有變動就要檢入一次。
iv. 為配合檢查、備份工作，需在檢查備份周期前全部check in (不保持check out)并退出登錄。詳見“檢查及備份”部分
3、 檢出：即check out。原則上只對要修改的文檔方可檢出。
4、 破壞（Destroy）：一般情況不可以破壞文件、目錄。
5、 如果是誤操作，則可在一天內(nèi)提交管理員處
6、 如果超過一天，則需要由項目經(jīng)理同意，且管理員破壞前要備份。
7、 各階段環(huán)境職責(zé)
配置項發(fā)布是指配置項進行到一定的階段（例如，里程碑階段），需要對外發(fā)布時的規(guī)則。在我們的項目中，配置項發(fā)布是通過標(biāo)簽，即LABEL，來實現(xiàn)的。
基線確立與變更 ，基線的確定在上一部分中已經(jīng)說到過，我們的項目基線分為兩類，一類是作為里程碑和其他工作依賴的基線（例如需求文檔、設(shè)計文檔等），另一類是開發(fā)過程中有必要保留的一種狀態(tài)（例如代碼過程中某個模塊的一個有保留價值的snapshot）。對這兩種不同的基線，其影響的范圍不同，確立和變更方式也不一樣。
我們項目的基線變更控制委員會由客戶代表、產(chǎn)品經(jīng)理、項目經(jīng)理以及技術(shù)經(jīng)理組成，對發(fā)布的里程碑類基線的變更必須由變更控制委員會確認(rèn)并由QA進行變更記錄，所有被變更影響的配置項都需要重新同步后再次發(fā)布；而對于僅僅作為工作狀態(tài)保留的基線，一般只需要建立基線的小組確認(rèn)更改并在QA進行記錄即可。
通過該項目的配置管理和實施，應(yīng)該說，這次我們對項目的配置管理實施是非常成功的，在整個開發(fā)過程中，基本沒有出現(xiàn)因為配置管理的問題導(dǎo)致的對開發(fā)進度的延誤。當(dāng)然，在開發(fā)過程中也發(fā)生了由于需求變化導(dǎo)致基線變更引起開發(fā)進度的延遲，不過這不應(yīng)該算作是配置管理的失誤，因為作為配置管理來說，只能盡量保證基線變更不會導(dǎo)致項目失控。選擇一個合適的配置管理工具絕對是必要的，我們在前面用了一章多的篇幅介紹我們使用的配置管理工具及其方案，事實證明，我們選擇的配置管理工具對我們項目管理實施的效果是決定性的。 在配置管理實施的初期，及時的指導(dǎo)起的作用是巨大的，甚至可以說是成功的主要因素；對不熟悉配置管理的開發(fā)工程師來說，配置管理工作容易在一開始就讓他們產(chǎn)生厭煩情緒，一點點使用上的不方便就會導(dǎo)致開發(fā)人員對配置管理的怨言，這個時候，及時的指導(dǎo)就顯得非常重要了，我們在配置管理實施過程中，準(zhǔn)備了《VSS操作手冊》、《SOS簡明操作手冊》、《配置管理操作指導(dǎo)書》等手冊，進行了三次的培訓(xùn)，并在實施過程中隨時解決開發(fā)人員在使用配置管理工具中的問題。而且，在實施初期，我們以獎勵為主，在一個月的時間內(nèi)沒有將配置管理工作作為考核內(nèi)容。 在配置管理基本走上正規(guī)后，每周的配置狀態(tài)檢查是我們對配置管理執(zhí)行效果的檢查，一旦發(fā)現(xiàn)問題，會作為QA問題報告發(fā)出并要求限期改正。如果沒有這個檢查制度，配置管理工作很難持續(xù)受控。