我把這樣一個小程序叫做Surveillant，也就是監視者的意思，當然還有監督者、密探的意思。我想配置管理員和測試人員會喜歡這樣一個名字的。但是我并沒有其它的企圖，只是通過這樣一個小程序幫助有需要的人方便地、自動化地獲取需要的信息。
用C#來寫這樣一個小程序，我們可以有兩個選擇，一種是調用命令行的方式，一種是使用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#的代碼里只要把其中的項目路徑、用戶帳號、日期等替換掉，再通過啟動一個命令行進程來執行它即可。使用這種命令行方式的前提是把SSDIR環境變量設置好了，也就是說把要連接的VSS數據庫的srcsafe.ini文件所在的路徑設置成環境變量了。
如果是用VSS的自動化編程接口，首先要加入對Microsoft.VisualStudio.SourceSafe.Interop.dll的引用。然后建立一個vss數據庫實例的引用，用Open方法登錄：
|
VSSDatabase vssDatabase = new VSSDatabase(); vssDatabase.Open(SSDIR, userName, passWord); |
然后通過get_VSSItem方法指定需要獲取變更歷史的源代碼項目路徑，返回一個IVSSItem對象：
| IVSSItem vssFolder = vssDatabase.get_VSSItem(projectPath, false); |
利用這個對象來遞歸地訪問項目中的所有源代碼文件。在這里我用一個叫getVssHistory的遞歸方法來實現訪問所有項目源代碼文件在指定的日期范圍內的版本歷史：
|
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) { //如果是在指定時間范圍內的版本，則納入返回結果 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的對象模型，獲取更多你需要的信息。例如所有當前處于簽出狀態的文件，某個VSS用戶的權限，等等。
把小程序納入每日構建的執行框架中，或者就簡單地利用Windows的任務計劃每天晚上定時執行，獲取當天的VSS配置庫的更改信息，或者其它需要的信息，在第二天早上把這份小小的報告放在每個人的郵件中，每個人都能從這些報告中獲得需要的信息。
程序的使用
完整的程序源代碼可以到我的搏客下載。
http://www.kjueaiud.com/?141783/action_viewspace_itemid_64835.html
其實這樣一個程序對于開發人員也是非常有用的，我們經常發現自己的bug修改好了，但是過幾天又被reopen了，原因是改好的程序又被某個魯莽的家伙覆蓋了。如果每天都能知道其他人在昨天做了什么更改，尤其是清楚是否對自己的“敏感地帶”動了手腳的話，很多源代碼控制的問題也就能及早發現并修正了。
但是更重要的是要把這些記錄作為溝通的信息。作為配置管理員，即使是在不規范的配置管理流程中，也需要做好配置庫的更改記錄和審計工作，當發現某些文件的更改非常頻繁，或多人頻繁交替更改同一個文件時應該主動問個究竟；當測試人員發現昨天存在源代碼的更改時，應該主動聯系更改的開發人員，具體了解更改的內容，更改涉及的范圍是什么，是否需要及時進行測試，對自動化測試腳本是否有影響，等等。
流程的改進是一個循序漸進的過程，如果改進比較緩慢，或者停滯不前，不要等待某個人來搭救我們，自己先想想，有什么東西可以做的，不要依賴流程，更不要互相埋怨，畢竟流程是為了幫助我們建立正確的做事方式，減低出錯的機會，而要想做對事情，前提是建立起正確的思維。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
