在VSS中監(jiān)視你的軟件配置和管理數(shù)據(jù)庫
軟件配置管理，也叫SCM，是一個軟件組織質(zhì)量改進(jìn)碰到的第一個瓶頸，因為SCM的核心是進(jìn)度控制和風(fēng)險管理，而這兩項是所有迫切需要進(jìn)行質(zhì)量改進(jìn)的軟件組織的最大弱點。
SCM的殘酷現(xiàn)實
但是在改進(jìn)過程中，我們會碰到太多的阻力，其中一個重要的阻力是配置管理流程的執(zhí)行問題。開發(fā)人員認(rèn)為配置管理約束了他們的自由的創(chuàng)作，配置管理員也不知道如何進(jìn)行配置管理活動。這些情況在中小型軟件企業(yè)中普遍存在。
管理層不能狠下決心結(jié)合配置管理來做好進(jìn)度和風(fēng)險的控制，配置管理的流程和制度名存實亡，配置管理員在這樣的環(huán)境下，可能很難想象自己除了寫寫無聊的配置管理計劃和報告之外，究竟要做些什么工作。
另一方面，由于配置管理流程沒有真正建立起來，測試人員也在發(fā)牢騷，因為他們永遠(yuǎn)也不知道開發(fā)人員在什么時候又改動了一行代碼，結(jié)果導(dǎo)致他們測試的遺漏，或者是開發(fā)人員一時興起，把大部分控件的名稱改成更好聽的名字，結(jié)果導(dǎo)致測試人員的自動化腳本需要重新錄制。
VSS是大部分中小軟件企業(yè)都在使用的配置管理工具。把它稱為配置管理工具實在有點勉強，因為缺乏構(gòu)建管理、流程管理等功能，充其量也不過是個源代碼控制工具。但是就是這樣一個小工具，卻是我們大部分人用在配置管理活動中的核心工具。
在這樣“殘酷”的環(huán)境中，真的就只能互相埋怨，被迫接受現(xiàn)實了嗎？不，基于VSS，我們還是可以主動的獲取很多信息來真正幫助我們。
VSS的編程接口
VSS提供了2種類型的編程接口，命令行，自動化接口。VSS的SS.exe通過命令行調(diào)用，支持大部分的VSS界面操作的功能。例如通過Checkin 和Checkout命令來簽入、簽出文件。
VSS還提供了一個自動化編程接口IVSS，IVSS是一個基于COM的自動化接口集合，通過Microsoft.VisualStudio.SourceSafe.Interop命名空間暴露給用戶使用。它提供了操作VSS數(shù)據(jù)庫的接口。例如，通過IVSSDatabase接口訪問和登錄VSS數(shù)據(jù)庫。
每日配置管理簡報
既然，VSS提供了方便的編程接口，那么我們能否利用它來幫助我們進(jìn)行配置管理活動呢？答案是肯定的。其中一個簡單的活動是配置管理記錄的自動生成。
我們可以在每天晚上下班后運行一個小程序，自動登錄到VSS，獲取當(dāng)天開發(fā)人員對VSS做的任何改動。并記錄到文件中，作為配置管理記錄，并且發(fā)送到項目組各成員的郵箱中，這樣測試人員也可以在每天早上上班的時候知道昨天開發(fā)人員進(jìn)行了哪些更改，是否需要取版本進(jìn)行回歸測試，回歸測試的策略也可以方便地根據(jù)配置管理記錄來進(jìn)行設(shè)計。
Surveillant
我把這樣一個小程序叫做Surveillant，也就是監(jiān)視者的意思，當(dāng)然還有監(jiān)督者、密探的意思。我想配置管理員和測試人員會喜歡這樣一個名字的。但是我并沒有其它的企圖，只是通過這樣一個小程序幫助有需要的人方便地、自動化地獲取需要的信息。
用C#來寫這樣一個小程序，我們可以有兩個選擇，一種是調(diào)用命令行的方式，一種是使用VSS的自動化編程接口。
命令行的方式比較簡單，使用SS的History命令即可，例如：
History $/vss_test -R -Yusername,password –Vd2007-10-18;23:59:59~2007-10-18;00:00:00 -O@C:\report.txt;
在C#的代碼里只要把其中的項目路徑、用戶帳號、日期等替換掉，再通過啟動一個命令行進(jìn)程來執(zhí)行它即可。使用這種命令行方式的前提是把SSDIR環(huán)境變量設(shè)置好了，也就是說把要連接的VSS數(shù)據(jù)庫的srcsafe.ini文件所在的路徑設(shè)置成環(huán)境變量了。
如果是用VSS的自動化編程接口，首先要加入對Microsoft.VisualStudio.SourceSafe.Interop.dll的引用。然后建立一個vss數(shù)據(jù)庫實例的引用，用Open方法登錄：
VSSDatabase vssDatabase = new VSSDatabase();
vssDatabase.Open(SSDIR, userName, passWord);
然后通過get_VSSItem方法指定需要獲取變更歷史的源代碼項目路徑，返回一個IVSSItem對象：
IVSSItem vssFolder = vssDatabase.get_VSSItem(projectPath, false);
#p#
利用這個對象來遞歸地訪問項目中的所有源代碼文件。在這里我用一個叫g(shù)etVssHistory的遞歸方法來實現(xiàn)訪問所有項目源代碼文件在指定的日期范圍內(nèi)的版本歷史：
public void getVssHistory(ref StringBuilder result,IVSSItem vssFolder,DateTime from,DateTime to)
{
IVSSItems items = vssFolder.get_Items(true);
foreach (IVSSItem item in items)
{
//判斷是文件還是目錄
if (item.Type != 0)
{
IVSSVersions versions = item.get_Versions(1);
foreach (IVSSVersion version in versions)
{
//如果是在指定時間范圍內(nèi)的版本，則納入返回結(jié)果
if ((version.Date > from) && (version.Date < to))
{
result.AppendLine(item.Spec + " ( version "
+ version.VersionNumber.ToString() + " ):"
+ version.Date + " , " + version.Action
+ " by " + version.Username + "\n");
}
}
}
else
{
//如果是目錄，還需要遞歸下去
getVssHistory(ref result,item, from, to);
}
}
}
可以充分利用IVSS的對象模型，獲取更多你需要的信息。例如所有當(dāng)前處于簽出狀態(tài)的文件，某個VSS用戶的權(quán)限，等等。
把小程序納入每日構(gòu)建的執(zhí)行框架中，或者就簡單地利用Windows的任務(wù)計劃每天晚上定時執(zhí)行，獲取當(dāng)天的VSS配置庫的更改信息，或者其它需要的信息，在第二天早上把這份小小的報告放在每個人的郵件中，每個人都能從這些報告中獲得需要的信息。
程序的使用
完整的程序源代碼可以到我的搏客下載 http://www.51testing.com/?141783/action_viewspace_itemid_64835.html
其實這樣一個程序?qū)τ陂_發(fā)人員也是非常有用的，我們經(jīng)常發(fā)現(xiàn)自己的bug修改好了，但是過幾天又被reopen了，原因是改好的程序又被某個魯莽的家伙覆蓋了。如果每天都能知道其他人在昨天做了什么更改，尤其是清楚是否對自己的“敏感地帶”動了手腳的話，很多源代碼控制的問題也就能及早發(fā)現(xiàn)并修正了。
但是更重要的是要把這些記錄作為溝通的信息。作為配置管理員，即使是在不規(guī)范的配置管理流程中，也需要做好配置庫的更改記錄和審計工作，當(dāng)發(fā)現(xiàn)某些文件的更改非常頻繁，或多人頻繁交替更改同一個文件時應(yīng)該主動問個究竟；當(dāng)測試人員發(fā)現(xiàn)昨天存在源代碼的更改時，應(yīng)該主動聯(lián)系更改的開發(fā)人員，具體了解更改的內(nèi)容，更改涉及的范圍是什么，是否需要及時進(jìn)行測試，對自動化測試腳本是否有影響，等等。
流程的改進(jìn)是一個循序漸進(jìn)的過程，如果改進(jìn)比較緩慢，或者停滯不前，不要等待某個人來搭救我們，自己先想想，有什么東西可以做的，不要依賴流程，更不要互相埋怨，畢竟流程是為了幫助我們建立正確的做事方式，減低出錯的機會，而要想做對事情，前提是建立起正確的思維。
【編輯推薦】
