軟件配置管理作為貫穿軟件開發過程始終的一項工作，其重要性不言而喻。51cmm上已有眾多關于配置管理介紹、配置管理計劃、配置管理工作開展心得一類的文章，這些文章從概念和實施上介紹了配置管理工作的內容，但美中不足的是仍嫌抽象，那些想要依葫蘆畫瓢的兄弟姐妹們在試圖將這些理論應用到自己項目的配置管理中的時候，會發現仍然是無從下手（我也曾是這些感覺無從下手的人中的一個）。因此，本文擬從另外一個角度，以本人最近實際操作的一個項目的配置管理工作談起，從配置管理工具的選擇、配置管理流程制定、配置管理庫結構的確定，以及作為配置管理工作的推動者如何推動這項工作等方面仔細描述一下本人的做法，希望這幾篇文章能給那些水深火熱中的兄弟姐妹們一點幫助。

 

這里有兩點需要特別說明：

 

1．本文描述的內容是以一個項目的配置管理為主線，對組織級的配置管理和配置管理策略沒有進行詳細討論；

2．本文用來做示例的項目是一個“工程型”的項目，所謂的“工程型”是和“產品型”對應的，這樣的項目需要公司的開發人員和現場的開發人員進行協作開發，一般而言，在公司的開發人員完成大部分的功能，現場的開發人員根據用戶需求，對軟件進行修改（這部分的工作量一般會較大，在一個16人年的項目中，這部分的工作可能會占到三分之一以上的工作量）。

 

配置管理工作概述

 

配置管理工作的工作范圍，在51cmm的很多文章中都有描述，具體可以參考河清專欄的《基于CMM和CMMI的配置管理》和陳越的《軟件配置管理實施體會》。在這里不作詳細的描述。

 

本文涉及的項目背景

 

本文用來示例的項目是某省電信的一個項目，該項目的工作量大約是16人年，項目周期約為1年。大部分（90%以上）的開發工作在前8個月內完成，后期的工作主要由維護人員進行系統維護和調整。在8個月的開發時間中，前5個月由開發人員在公司進行開發，根據用戶的需求完成設計，確定系統架構并實現整個框架，部分明確的功能以及公用模塊也在這段時間內完成；后3個月的時間部分開發人員在現場，部分開發人員在公司共同完成后期的開發工作。

 

整個項目采用的開發語言是C++、Java、ASP，涉及的平臺包括Solaris和Windows，采用的開發工具包括Visual Studio和Solaris上的CC。此外，整個項目還使用了一些第三方的平臺，如IBM的MQ等。

 

除用戶需求之外，公司還對項目組提出了代碼復用方面的要求，開發人員在開發過程中必須注意代碼的可重用性。

 

配置管理前期準備工作

 

在項目正式啟動之后，配置管理工作就可以開始了。配置管理工作開始的第一步就是一份配置管理計劃。51cmm上已有不少配置管理計劃的模板，大家可以參考。

 

一般而言，需要在配置管理計劃中明確的內容包括：

 

1、 配置管理軟硬件資源；

2、 配置庫結構；

3、 人員、角色以及配置管理規范；

4、 基線計劃；

5、 配置庫備份計劃；

在下文中，我們將圍繞這些內容進行詳細描述。

 

配置管理環境

 

配置管理環境包括軟硬件環境。具體的資源需求應該根據項目實際情況來確定，一般需要考慮的包括：網絡環境、配置管理服務器的處理能力、空間需求，配置管理軟件的選擇等。配置管理環境的確定需要綜合考慮各個方面的因素，包括我們采用的開發工具，開發方式，開發人員對配置管理工具的熟悉程度等，其中，開發人員對配置管理工具的認可和熟悉程度常常直接決定配置管理能否正常進行，如果選擇了需要開發人員花費比較大的精力去熟悉的配置管理軟件，我們就必須花費大量時間來進行培訓；同時，配置管理軟件和開發工具的集成程度也是一個必須考慮的因素，根據我們的經驗，選擇一個和開發環境集成緊密的配置管理工具至少可以減少20%花費在Check In/Check Out和配置管理人員保持配置庫完整上的工作量。

根據我們項目的實際情況，我們有如下一些考慮：

根據歷史經驗，一個類似項目的配置庫大小約為3G，考慮到備份等操作對空間的需求，至少應該為配置管理庫保留10G以上的空間。為了保證配置管理庫的安全，除了相應的備份計劃之外，還可以采用了RAID 0＋1的方式為配置數據庫提供更好的可用性保證；

考慮到在項目的后期有部分開發人員會在現場進行開發，因此在網絡條件上需要提供對遠程訪問方式的支持；

配置管理服務器的選擇和配置管理軟件的選擇相關，考慮到目前公司有一臺閑置的PC服務器，最好能充分利用這臺服務器；

配置管理軟件必須可以以某種方式支持遠程訪問，而且由于我們的開發平臺涉及Solaris和Windows，配置管理軟件要能夠支持這兩種平臺；考慮到開發工具方面，配置管理工具要求能和我們選擇的開發工具進行很好的集成；

項目組的開發人員缺乏使用配置管理工具的經驗，有將約30%的開發人員使用過VSS配置管理工具，但僅限于最基礎的使用，對VSS的Label等功能沒有概念；結合以上的情況，我們首先考慮配置工具的選擇。

配置管理工具的選擇

從開發人員具有的配置管理工具使用經驗和配置管理工具使用的難易度方面來說，VSS是最好的選擇，在現有的基礎上只需要對開發人員進行簡單培訓；考慮到和開發工具的集成，VSS也是一個不錯的選擇。不過本項目還要求對遠程接入方式的支持，以及對Solaris平臺的支持，VSS肯定是不能滿足要求的（VSS通過VPN方式應該是可以實現對遠程訪問的支持，但VSS的完全共享方式實在是不敢在Internet上使用）。

除VSS外，可以選擇的配置管理工具還有CCC Harvest、ClearCase、CVS等，但Harvest和ClearCase使用起來比較復雜，需要一個專門的配置庫管理員負責技術支持，還需要對開發人員進行較多的培訓，另外，Harvest和ClearCase價格不菲；CVS在Unix下使用方便，而且是免費的，但其文本方式的操作界面對于習慣在Windows平臺上開發的開發人員來說使用非常不習慣（CVS也有windows下的GUI版本，但經過我們的試用，在操作習慣上和我們目前開發人員習慣的方式很不相同，較難被接受）。

經過在MSDN和Internet上查找，終于找到了一個VSS的增強軟件SOS（Source Offsite），它基于VSS的數據庫，可以支持通過TCP/IP方式訪問和操作VSS庫，在Windows、Slolaris和Linux上都提供了客戶端，并且通過傳輸數據的壓縮和加密方式，使得文件操作的速度大大加快并增強了系統的安全性。SOS可以在SourceGear的網站上找到詳細介紹和試用的下載（http://www.sourcegear.com/sos）。事實證明，VSS＋SOS的組合在我們的整個項目過程中起到了關鍵的支持作用。我們使用的SOS是3.53的Standard版本，本文也將以該版本為例在下一部分中說明具體的操作和使用步驟。

軟硬件環境的選擇

確定了配置管理工具后，我們使用公司購置的一臺Compaq PC Server作為配置管理的硬件環境，該服務器配置如下：

CPU：1CPU，P4 2.0G

內存：512M DDR

硬盤空間：30G×4

網卡：HP G bit網卡一張

最終確定的方案是安裝該服務器安裝Windows 2000 Server操作系統，為了保證配置數據的安全性，我們采用RAID 0＋1方式，總的可用空間在50G左右；另外為了備份的需要，還為服務器配置了一個CDR刻錄機。

網絡環境的選擇

公司已有現成的100M局域網，通過一個交換機和路由器連接至Internet，有一個公網的靜態IP；配置管理服務器是內網的一臺機器，具有一個內網IP。為了滿足遠程訪問的需要，我們通過在路由器上設置端口映射，將SOS需要使用的端口映射到配置管理服務器上（缺省情況下，SOS使用8888和8890兩個端口）。

在公司的開發人員通過局域網使用VSS訪問和操作配置庫，在現場的開發人員通過Internet接入對配置庫進行訪問和操作。

配置庫維護和備份計劃

配置庫的維護的備份需要專職的配置庫管理員來負責。在整個項目中我們采用的配置庫維護策略是根據Microsoft的Best Practice白皮書建議，包括以下要點：

1．保持配置數據庫的大小不超過5G；Microsoft建議，配置庫的大小在3－5G比較合適，太大的數據庫會極大影響VSS的效率；減小配置庫大小的

2．每周進行VSS數據庫的分析（Analysis），發現問題及時修正；VSS提供了Analysis和Fix工具，由于不合理的Delete等操作，VSS數據庫有可能會出現一些Interrupt Data之類的問題，通過定期的每周的分析工作，可以極大減少數據庫出現問題的風險；

3．每日進行配置庫的增量備份，每周進行數據庫的完全備份；VSS庫的備份可以通過VSS自己的Archive功能或者是操作系統的Backup程序來進行。VSS的Archive功能對VSS中的文件數據進行壓縮并保留VSS的所有狀態，但只能對VSS庫進行完全備份，不能實現增量備份功能。

 Windows2000 Server提供的Backup實用程序可以對文件進行備份，由于VSS庫就是以文件形勢存在的，因此針對VSS的data目錄進行備份也可以完全達到備份的目的，使用系統備份工具的好處是可以實現增量備份。我們在實際中使用的系統的備份工具，每周五生成的完全備份采用刻錄光盤的方式保存，每天的增量備份數據存放在文件服務器上進行備份。

【編輯推薦】

1. Gartner：長期使用SaaS企業費用偏高
2. 對話阿里架構師：走進SaaS應用開發
3. 經濟危機促使SaaS全面向電子商務過渡