TFS(Team Foundation Server)介紹



關於MSDN上TFS介紹請點擊：http://msdn.microsoft.com/zh-cn/library/ms253108.aspx

在本文的兩個部分中，我將介紹Team Foundation Server的一些核心特徵，重點介紹在本產品的平常應用中是如何將這些特性結合在一塊兒使用的。

做爲一名軟件開發人員，在個人職業生涯中，我常常會用到支持軟件開發過程的大量開發工具，如版本控制工具、漏洞跟蹤包、生成腳本語言、單元測試框架和需求分析工具等等。在.NET平臺上，大量的支持工具可以很好地獨立工做，可是，爲了使得各類工具之間都夠互相協做，仍是常常須要一些手動工做。

隨着Visual Studio產品線中Team Foundation Server組件的發佈，微軟使得開發團隊在僵化的軟件工程實踐應用中取得了巨大進步。這並非由於該產品包含的各類新增特性必定是最好的，關鍵因素是它的集成性。

Team Foundation Server起步

Team Foundation Server(TFS)是這樣一種服務器產品，它須要部署到軟件開發環境中，這樣開發人員就可使用它提供的各類服務。由於TFS是設計用於大規模團隊，於是有兩種拓撲結構供選擇：雙服務器和單服務器。

在單服務器部署中，TFS被安裝在Windous 2003 server上，且該機器上已安裝了SQL Server 2005數據庫服務器、Web服務器IIS以及windows SharePoint Services。這種類型的安裝能夠知足大量用戶需求，而且適用於大部分條件。

雙服務器部署將SQL Server 2005 的數據庫引擎和分析服務組件分開安裝在不一樣的機器上，這樣就能夠實現可擴展性（經過增大用於大量用戶註冊操做的空間以及將處理負載的不一樣數據倉庫安裝在不一樣的機器上實現，這種機器最大可達64位。）

安裝了TFS服務器後，客戶端能夠經過安裝Team Explorer來訪問服務器。Team Explorer是一組組件，它包括簡單版本的Visual Studio 2005（若是是在已經安裝了Visual Studio 2005的機器上就僅僅是再添加更多功能）和大量用於微軟的Excel和Project的插件，利用Excel和project能夠訪問存儲在Team Foundation Server數據庫中的數據。

Team Explorer可用於訪問Team Foundation Server的如下特性：

• 過程引導
• 工做項跟蹤
• 版本控制
• 自動生成
• 報告

建立一個團隊項目

在開發團隊可使用Team Foundation Server以前，必須先建立一個團隊項目，團隊項目表明瞭一個全部團隊活動都在這裏發生的管理單元。爲了建立一個團隊項目，Team Foundation Server管理員須要打開Visual Studio 2005和 Team Explorer工具窗口（從視圖菜單）。當打開Team Explorer 窗口後，就能夠創建一個到服務器的鏈接。

右鍵單擊樹狀視圖中的服務器節點，TFS管理員就能夠選擇「新建團隊項目」。事實上，這個選項一般是隱藏的，可見須要新建一個團隊項目的狀況是不多的。絕大部分狀況下，一個軟件開發團隊在一個大型軟件的生命週期中僅有一個團隊項目。

建立團隊項目時，開發小組須要作的第一件事情是決定使用那個開發模型。

選擇開發模型

Team Foundation Server容許開發小組選擇他們想要使用的任何特定軟件開發方法。下面的列表中提供了兩種開發模型：

• 敏捷模型驅動軟件開發
• 能力成熟度集成模型軟件開發

每一個開發模型都有一組特有的定製特性，包括定義工做項（要作的事情、要肯定的事情、需求等等），過程管理和報告。下表顯示了兩個默認的開發模型中不一樣工做項的分解：

敏捷模型驅動軟件開發	能力成熟度集成模型軟件開發
漏洞 服務要求的質量 風險 場景 任務	漏洞 改變請求 問題 需求 回顧 風險 任務

在這種狀況下即便工做項的數目和名稱存在差別，也應該指明使用這兩種開發模型通用方法，而不是開發小組來推測他們該如何使用這些工做項類型，開發模型能夠包含一些可選的過程管理頁面。

 

若是對話框中的模型不適合你的具體要求，能夠訂製它們以知足你的要求。事實上，已經有大量能夠得到的第三方開發模型，如Scrum and process MeNtOR。 

訪問工做項存儲器

建立了團隊項目後，開發小組須要作的第一件事是分解已經建立的初始工做項集。這些工做項幫助開發人員完成一系列可使得軟件項目成功開始的活動，而且依據不一樣的開發模型選擇不一樣的工做項。經過展開團隊項目節點，就能夠看到工做項文件夾，繼續展開而後打開查詢文件夾可看到所有或部分工做項。

書寫定製得工做項查詢

最後須要書寫一個新的工做項查詢列表。新定義的查詢能夠放在「團隊查詢」和「個人查詢」這兩個文件夾的任何一個。團隊查詢是一個可被項目小組中的全部開發人員訪問的全局可訪問容器，個人查詢是一個由每一個程序開發員全部的私有查詢集。

我常用的一個有用的查詢是Recycle Bin query，這個查詢可用於打開最近關閉又須要從新打開的工做項（偶然關閉工做項的狀況時有發生）。第一步是從工做項節點的背景菜單中選擇「添加查詢」。

在查詢編輯器打開後，簡單的用戶接口就能夠基於某些簡單的表達式從工做項列表中過濾出須要的項目。在上面的狀況中，查詢設置爲返回當前狀態爲關閉的團隊項目中的全部工做項。 

應用Team Foundation Server的版本控制

訪問了工做項，就能夠應用Team Foundation Server中的版本控制。像TFS中的其它特徵同樣，版本控制功能位於SQL Server 2005之上，用於提供良好的性能和可擴展性（實際上，宿主在TFS中的版本控制存儲器的大小估計有千兆字節。開發小組可能遇到的第一個與版本控制相關的工做項是遷移已經存在的源代碼，這個工做項提供了在遷移源代碼是須要作什麼的詳細視圖。

 

配置一個工做區

在程序員將文件添加到版本控制存儲器以前，須要將版本控制存儲器的邏輯結構映射到本地機器上的文件系統。Team Foundation Server 引入了工做區的概念。工做區是物理位置和文件系統間的一組映射，一個文件系統與一個特殊用戶和計算機組合相匹配。在文件上進行工做的程序員，他們是邏輯的進出工做區。爲了創建一個工做區，程序員須要雙擊Team Explorer中的源碼控制圖標，到工做區下拉菜單。

 

我發現將整個源代碼樹的根映射到本地驅動器上的一個具體位置並將其做爲惟一映射是最簡單的方法。我本身的方法是在個人數據驅動器的根目錄上建立一個「沙盒」目錄，在它的下級有一個子目錄，將其命名爲我鏈接到的TFS服務器的名字。（我鏈接到了多個TFS服務器，所以必定要注意避免混淆）。

創建了映射以後，瀏覽源代碼控制瀏覽器將會列出源代碼樹上邏輯位置的本地路徑。至此你就能夠添加源代碼到這個容器中。

程序員面對的一個侷限是他們不能將文件添加到版本控制存儲器的根中（$/），且全部以及文件夾都直接和某個特定團隊項目相關。這裏面的邏輯是，一個Team Foundation Server可用於大量項目，每一個項目應該在它們本身的區域內工做。 

 

添加源代碼到Team Foundation Server

在Team Foundation Server中安排源代碼有無數的方式，你爲何選用這種而不用另外一種，詳細的緣由說明超出本文的範圍。下面選擇的方式僅是一個用於演示例子。特別的地方是，我選擇添加了三個字文件夾：Trunk, Branches 和Releases，以下圖。

文件夾添加到版本控制系統後，其餘的程序員並不會當即看到，他們必須像文件同樣進行註冊。在本例中，在註冊前我將添加一組解決方案和項目文件到這個容器中，而後一塊兒註冊。

 

除了加強了性能和擴展性外，TFS將其版本控制系統安裝在SQL Server 2005上，這意味着，進行原子提交和註冊的方法是可能的。也就是說，要麼所有註冊成功，要麼所有失敗。註冊能夠在源代碼控制瀏覽器或解決方案瀏覽器上執行（或者在強制改變工具窗口中進行）

版本控制系統和工做項存儲器在註冊時集成在一塊兒。當註冊時，能夠將其與一個或多個工做項關聯。例如，由於這是剛引入源代碼，因此我能夠瀏覽註冊對話框中的工做項視圖，選擇工做項3387和它關聯。注意當關聯工做項時不管默認的選擇如何都要將註冊行爲設定爲 「解決」，這樣作的目的是防止任務關閉工做項，所以較早創建十分有用的Recycle Bin 查詢。

 

創建一個註冊，就叫作一個改變集，一個源代碼容器不過是一系列不斷彼此堆積起來的改變集。由於在數據庫中改變集是一個能夠區分的實體，所以能夠將數據和它關聯在一塊兒，因此上面創建的改變集和工做項3387的關係能夠在改變集中瀏覽或者在工做項中瀏覽。下面的屏幕截圖顯示了連到工做項的改變集。

和Team Foundation Server中的版本控制相關的一個新概念是擱置集。擱置集的思想是程序員在過週末休息時，能夠將在工做日作的改變放在某個安全的地方。創建一個擱置集至關簡單，首先，程序員在解決方案瀏覽器中的背景菜單中選擇「擱置必要的改變」，而後出現下面的對話框。

程序員能夠給擱置集一個名字，以便之後能夠查找和恢復它，和註冊對話框同樣，擱置集也能夠添加評論和關聯工做項。擱置集僅包含修改過的文件，由於改變集版本是從版本控制存儲器引出的，因此建立他們的至關簡單。

爲了恢復擱置集，能夠選擇背景菜單中的「解凍必要改變」選項，程序員能夠查找由他們或其餘程序員創建的擱置集。

事實上擱置集能夠共享，這意味着它們能夠很好的執行代碼預覽，加強單註冊點策略，這對一個特別項目在封裝時可能很十分有用。

在本文的下一部分，我將詳細介紹擱置集，TFS中完善的分支支持，TFS是如何支持自動生成的並介紹一下報告功能提供的功能。

 

功能介紹一：微軟最新配置管理工具

在當今的環境下，公司業務愈來愈複雜，軟件開發複雜度也愈來愈高，此時發如今衆多項目中時有這樣的現象發生：文檔散落在不一樣地方，代碼缺失，代碼和文檔不一致，同一系統多個版本，各項目採用不一樣配置管理工具、無統一的規範，隨着時間推移咱們的項目管理風險不斷上升、項目實施難度不斷增長、項目實施質量難以掌控。如何可以快速地構造出高質量的應用系統來知足不斷變化的業務增加所帶來的需求？咱們急須要創建一套完善的配置管理體系，來提升生產效率，提升產品質量，最終實現企業效益最大化。現階段配置管理面臨的挑戰是：

l  統一的規範

l  更好的組織性，更高的開發管理水平

l  保護投資 ：企業級的過程歷史數據、經驗、數字化資產

l  創建標準的開發環境

l  實現並行開發，縮短產品面市時間

l  自動化管理

l  爲創造性的工做釋放更多的時間

l  員工更加專業

    而經過微軟的Team Foundation Server（TFS）實施軟件配置管理能夠有效解決這些問題，例如可以集中管理各項目的文檔、代碼，對項目中的文檔、代碼等的變化進行有效管理，可以方便地重現某個文件的歷史版本，可以從新編譯某個歷史版本，使文檔維護工做變得容易、可以使多團隊並行開發成爲現實，同時實行統一的配置管理流程可提升項目組間人員流動時的工做效率，也是對工做成果的一種有效保護。

功能介紹二：外包管理工具

隨着信息技術的飛速發展，軟件已進入了社會生活的方方面面，愈來愈多的企業將他們的業務系統構建在以軟件爲核心的系統之上，企業經過它們來爲本身的客戶提供快速優質的服務。正由於軟件已經成爲業務的基礎平臺，企業的核心競爭力在很大程度上取決於軟件系統的質量，要求軟件系統可以迅速適應業務需求的變化，同時保證軟件系統的高性能、高可靠性和可維護性。然而對於大部分企業而言，軟件開發並非他們所擅長的業務，加上軟件系統的複雜性及很高的質量要求，大部分企業都選擇將軟件開發項目外包出去，由專業的軟件開發（供應）商來負責軟件的開發。可是軟件外包並不意味着企業對於軟件的開發過程放手無論，企業應該創建與供應商之間的協議，而且監控供應商的開發過程，並對供應商提交的最終系統進行全面的驗收，從而完全保證供應商可以按時交付一個高質量的軟件系統。

軟件項目的成敗在很大程度上取決於對其開發過程的控制，這包括對質量、源代碼、進度、資金、人員等的控制。要進行有效的過程控制，僅僅依靠人的力量是不夠的，還須要有相應的管理工具支持以實現高效的「軟件生命週期管理」。然而因爲歷史和現實的緣由，軟件生命週期管理流程和工具在我國軟件行業中的應用並不普及，因爲缺少必要的管理流程和工具，不少企業在軟件外包項目中都會或多或少的遇到以下的問題：l 缺乏統一的開發管理流程指導，沒法保證項目的質量和成功率

l  開發出來的系統不能知足用戶或者業務需求

l 開發過程不透明，很難監控開發的進展狀況

l 不能及時瞭解項目的 進度，常常致使項目延期

l  沒法有效的控制項目的變動，增長了項目的風險

l 沒法有效實現多地的協同開發 ，增長外包開發成本（場地，差旅費）

l  軟件複用率低下，下降了企業的投資回報率

l  沒法開展規範化的測試工做 ，不少問題要到驗收階段纔會暴露出來

l  缺少軟件開發歷史數據的積累， 沒法準確估算項目成本

l  缺少必要的版本管理工具，系統在構建和發佈時產生問題

l  缺少相應的文檔，增長了維護和升級的難度

 

這些問題致使不少企業對外包項目不能進行有效的控制或是在開發中形成過多的資源浪費（各個系統間太多的重複開發），以及開發出來的系統不能響應市場快速的變化。這些問題直接下降了發包方企業的生產力，增長了企業運營成本。要從根本上切實提升軟件外包開發的管理水平，必須從多方面入手，引入先進的開發流程，借鑑業界的最佳實踐，以及構築高效的系統開發管理平臺是必然的選擇。

爲了解決上述的外包開發管理中的常見問題，咱們基於微軟最新發布的軟件生命週期工具，設計了微軟的軟件外包開發管理解決方案，可以對多平臺和地理分佈的開發團隊提供必要的開發流程指導，實現高效的項目管理，促進項目團隊的溝通，並提供了緊密集成的變動和配置管理系統，爲企業創建了先進的軟件協同開發管理平臺。