爲您的開發團隊找個好管家

【已發表於《程序員》2006年第11期,全名《爲您的開發團隊找個好管家——Visual Studio 2005 Team Foundation Version Control解析》】

《大宅門》裏有位胡總管,精明能幹、平易近人又忠厚仁義,協助白二奶奶將白家上上下下打點得井井有條,連最不安分的白景琦也敬他三分。如果將百草廳看作是一個軟件開發團隊,將白二奶奶看作是這個團隊的領導人,那麼誰來當這個“胡管家”呢?換句話說,誰能保證真正做到毫無私心,剛正不阿又精明能幹地幫助您管好開發團隊這個“家”呢?

我想或許一下子會冒出許多候選人來競爭上崗,比如Visual SourceSafe V6.0、CVS、Subversion等等優秀的版本控制軟件。而在我心目當中,已經有了一個更好的選擇,那就是Visual Studio 2005 Team Foundation Version Control(TFVC)。

或許在過去,不少人對Visual SourceSafe V6.0的印象並不太好;或許不少人選用了其它的版本控制軟件;甚至我曾經參加過一個團隊,竟然沒有用到任何版本控制……當然這一切已成爲過去,時代的步伐總是在前進的,TFVC的推出,很大程度上改進了過去在版本控制上存在的缺陷和不足,使得開發團隊可以更加緊密、高效地工作。

數據存儲與安全級別

過去VSS採用文件系統作爲後臺數據存儲,而TFVC則採用Microsoft SQL Server 2005。由此不難看出,TFVC具備更快更強的數據存儲能力和更高更完善的安全級別,同時也更加可靠和容易升級。TFVC提供了一個安全系統,賦予您更加細緻的文件操作權限。

安全級別

註釋

讀取 允許讀取一項
簽入 允許簽入一項
標註 允許標註一項
鎖定 允許鎖定一項
修改其他用戶的更改 用戶可以修改註釋、工作項集合或者關於尚未建立的裝置的記錄
解鎖其他用戶的更改 該用戶可以解鎖另一個用戶鎖定的項
撤銷其他用戶的更改 可以在一個有另一個用戶簽出的項上取消尚未決定的更改
管理標註 允許用戶標註更感以及更改標註
操作安全設置 指定用戶擁有更改項的安全性的許可
簽入其他用戶的更改 允許用戶簽入由其他用戶簽出的項

 

 

 

 

 

 

 

 

 


表1,Team Foundation Version Control提供的安全級別

TFVC不僅具備細緻的安全級別,同時還包括完善的審覈能力與報告能力,這些能力可以有效地節省使用者的時間。

通信結構

Team Foundation Version Control採用的通信結構是靠HTTP通過標準的Web服務來完成每一件事情。這就是的一個由分散在世界各地的開發小組所組成的開發團隊也能夠協同工作並且通過Internet訪問中心知識庫。爲了更好地完成這項工作,Microsoft還建立了一個TFVC代理服務器在後臺處理同步數據並且允許開發人員就近訪問最新版本的代碼。
通常來講,一箇中型或者大型的IT公司都具有數十甚至上百個大大小小的開發團隊,這些開發團隊不可能都擠在一棟大樓裏面工作而是分佈在各個地區的分公司裏。而在過去,可能每一個團隊都需要安裝一套版本控制軟件,並且建立和管理自己的知識庫。因此從本質上講,這依然是零散的。根據前面提到的TFVC在這方面的改進,就可以很好地改變以往的局面,它可以使得管理層能夠對它的開發團隊進行集中控制——不要懷疑它的能力,一套TFVC能夠支持大約550名處於活動狀態的開發人員以及按TB計算的數據,而它將此集中於一點並僅由一名管理員進行管理即可。

平臺無關性

既然開發團隊越來越大,使用的開發環境越來越多,那麼平臺的無關性也就顯得至關重要了。集成開發環境與版本控制軟件“能一起工作”和“能很好地一起工作”可以說是兩個概念,而這二者之間的差別往往會弄得開發人員相當頭疼。正如同樣是趙五爺和秦二爺作伴,白景琦和白敬業的兩次買藥就完全是兩種經歷和結局。是什麼導致的差別呢?兼容性應該佔很大一部分。TFVC採用HTTP和Web服務作爲通信媒介,也就有潛力提供很好的平臺無關性。是的,TFVC的開發團隊將這樣的潛力發揮得很好,目前,一些開源或者閉源項目以及應用程序都能夠很好地與Team Foundation Server集成在一起,這就意味着不管是什麼平臺,您都可以擁有一個公共的、易用的、企業級的版本控制系統。

易用性

既然擁有這麼多令人心動的特性,那麼易用性是否會變得很糟糕呢?一般來說,龐大的軟件往往都顯得比較專業,那麼我就通過幾個實際的操作來向您展示,TFVC其實像胡總管一樣“平易近人”。

Check Out Code
圖1,簽出代碼

安全性加強了,提供了更爲豐富的簽出策略,但是在操作上並未增加多少步驟。這些策略可以在開發人員試圖簽入代碼時提醒他們這樣做違反了某些規定的策略。這些策略可以由管理員來定義並且包含如下的規則:
●    源代碼必須被高級開發人員檢查;
●    單元測試必須覆蓋超過80%的代碼;
●    沒有與公共命名規範相違背;

更加高級的是,開發人員在簽入代碼的時候,可以將源代碼與工作項相關聯。代碼在簽入的同時會報告給Team Foundation Server,這時系統會生成關於跟蹤Code Churn、Bugs的報告以及項目完成的進度。

您可以制定一個簽入策略以確保簽入版本控制系統的每一項代碼文件都可以與一個具體的工作項相關聯。這樣做的好處在於使得項目經理、架構師以及其他一些參與者都可以通過報告來了解項目的進展程度,即使這個項目是由分佈在不同地區的多個小組共同來完成的。

Check In Code
圖2,簽入代碼

要將簽入項與工作項相關聯,您可以先選擇一個您想要簽入的文件,然後點擊“Work Items”按鈕來選擇需要關聯的工作項(見圖3),

Associating a check-in with a work item or multiple work items
圖3,選擇與簽入項關聯的工作項

通過關聯簽入項與代碼項,可以使得項目的進度能夠得到更緊密地跟蹤,並且這也使得開發人員可以更加容易地找到對應於系統某個特定的功能的代碼。

當然,您也可能會同時將多個工作項關聯到一個特定的簽入項上。事實上在很多情況下您可能將一個代碼文件或者一個架構圖關聯到3、4個或者更多不同的工作項上。比如說,您的代碼是用來解決某個被查出的bug的,因此它就需要被關聯到關於bug的這個工作項上。另外,代碼也可能是跟應用程序的某個特性有關,或者是服務質量需求等等,因此它需要被關聯到不同的工作項上去。最後您完成了由Team Foundation Build自動生成的bug修復任務,因此您需要將您的簽入項與該工作項進行關聯以報告該任務已紀完成。

另外,我們在項目開發過程中常常會遇到一些暫時無法解決的問題,有些可能會推到下一個版本去實現,有些則只是需要等待其它工作完成之後即可實現,無論情況怎樣,我們都不能將這些需要暫緩解決的任務棄之不管。那麼在TFVC中是如何來擱置(Shelve)和取消擱置這些任務的呢?

如果您需要擱置您的代碼,您只需要在版本控制資源瀏覽器窗口中選中它並且點擊“Shelve”按鈕,然後給擱置的代碼提供一個擱置器的名稱以便於將來取消它的擱置狀態。完成這些之後您就已經將您的代碼擱置起來了。

Source Control Explorer
圖4,版本控制資源瀏覽器

如果您需要取消代碼的擱置狀態,僅需要點擊“Unshelve”按鈕並且選擇您想要取消擱置的擱置器即可。

Unshelving Code
圖5,取消代碼擱置

當您在取消代碼擱置的時候可能會與本地修改過的代碼引起衝突,因爲被擱置的代碼並不限制您直接編輯被擱置的文件(這是的您可以擱置同樣代碼的多個版本)。當這種情況發生時,您將被告知引起了衝突並且面對解決衝突的選項。

Resolving Conflicts
圖6,解決衝突

擱置和取消擱置開創了一些新的開發代碼的可能性。如果用戶不知道該選擇哪一種用戶界面,這是開發人員就能夠提出多個不同版本的窗口或者頁面,每一個都具有不同的外觀和用戶體驗。每一個版本都能夠單獨地被擱置起來,當面對用戶的時候,這些版本能夠一次取消擱置狀態並且展示出來。

擱置的另一個用途是當您正在開發一個新的特性時解決一個必須要修復的bug。有了擱置機制,您正在開發的特性可以直接被擱置起來,將您的代碼停留在開發這項新特性之前的狀,然後回頭轉來修復那個bug。當這個bug被解決掉後,再把取消代碼的擱置狀態然後繼續開發。

這樣看來,代碼擱置的機制甚至可以被看作是一個救生員。因爲關於新特性的代碼實際上並沒有完成也不能通過簽入策略,但是您卻可以將它放在一邊開始另外的工作,甚至也可以將擱置的代碼發給別的開發人員去檢查,從而騰出手來專心去修復急待解決的bug。

總結

Team Foundation Server和Team Foundation Version Control提供了很多利大於弊的新特性,合理地利用這些特性,將會給您的項目開發工作帶來很多便捷與高效,同時也可以提升項目的管理質量,降低失敗的風險。

當然,Team Foundation Version Control並不是萬能的,我在這裏僅僅是爲您引薦一位精明能幹的新管家,希望能助您一臂之力!
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章