標籤:style http color 使用 strong width
在本文的兩個部分中,我將介紹Team Foundation Server的一些核心特徵,重點介紹在本產品的日常應用中是怎樣將這些特性結合在一起使用的。
作為一名軟體開發人員,在我的職業生涯中,我常常會用到支援軟體開發過程的大量開發工具,如版本號碼控制工具、漏洞跟蹤包、產生指令碼語言、單元測試架構和需求分析工具等等。在.NET平台上,大量的支援工具可以非常好地獨立工作,可是,為了使得各種工具之間都夠互相協作,還是常常須要一些手動工作。
隨著Visual Studio產品線中Team Foundation Server組件的公布,微軟使得Team Dev在僵化的軟體project實踐應用中取得了巨大進步。這並非由於該產品包括的各種新增特性一定是最好的,關鍵因素是它的整合性。
Team Foundation Server起步
Team Foundation Server(TFS)是這樣一種server產品,它須要部署到軟體開發環境中,這樣開發人員就能夠使用它提供的各種服務。由於TFS是設計用於大規模團隊,因而有兩種拓撲結構供選擇:雙server和單server。
在單server部署中,TFS被安裝在Windous 2003 server上,且該機器上已安裝了SQL Server 2005資料庫server、WebserverIIS以及windows SharePoint Services。這樣的類型的安裝能夠滿足大量使用者需求,而且適用於大部分條件。
雙server部署將SQL Server 2005 的資料庫引擎和分析服務元件分開安裝在不同的機器上,這樣就能夠實現可擴充性(通過增大用於大量使用者注冊操作的空間以及將處理負載的不同資料倉儲安裝在不同的機器上實現,這樣的機器最大可達64位。)
安裝了TFSserver後,client能夠通過安裝Team Explorer來訪問server。Team Explorer是一組組件,它包含簡單版本號碼的Visual Studio 2005(假設是在已經安裝了Visual Studio 2005的機器上就不過再加入?很多其它功能)和大量用於微軟的Excel和Project的外掛程式,利用Excel和project能夠訪問儲存在Team Foundation Server資料庫中的資料。
Team Explorer可用於訪問Team Foundation Server的下面特性:
- 過程引導
- 工作項目跟蹤
- 版本號碼控制
- 自己主動產生
- 報告
建立一個Team 專案
在Team Dev能夠使用Team Foundation Server之前,必須先建立一個Team 專案,Team 專案代表了一個全部團隊活動都在這裡發生的嵌入式管理單元。為了建立一個Team 專案,Team Foundation Server管理員須要開啟Visual Studio 2005和 Team Explorer工具表單(從視圖菜單)。當開啟Team Explorer 表單後,就能夠建立一個到server的串連。
按右鍵樹狀檢視中的server節點,TFS管理員就能夠選擇“建立Team 專案”。其實,這個選項一般是隱藏的,可見須要建立一個Team 專案的情況是非常少的。絕大部分情況下,一個軟體Team Dev在一個大型軟體的生命週期中僅有一個Team 專案。
建立Team 專案時,開發小組須要做的第一件事情是決定使用那個開發模型。
選擇開發模型
Team Foundation Server同意開發小組選擇他們想要使用的不論什麼特定軟體開發方法。以下的列表中提供了兩種開發模型:
- 敏捷模型驅動軟體開發
- 能力成熟度等級整合模型軟體開發
每一個開發模型都有一組特有的定製特性,包含定義工作項目(要做的事情、要確定的事情、需求等等),過程管理和報告。下表顯示了兩個預設的開發模型中不同工作項目的分解:
敏捷模型驅動軟體開發 |
能力成熟度等級整合模型軟體開發 |
漏洞 服務需求的品質 風險 情境 任務 |
漏洞 改變請求 問題 需求 回想 風險 任務 |
在這樣的情況下即使工作項目的數目和名稱存在差異,也應該指明使用這兩種開發模型通用方法,而不是開發小組來猜測他們該怎樣使用這些工作項目類型,開發模型能夠包括一些可選的過程管理頁面。
假設對話方塊中的模型不適合你的詳細要求,能夠訂製它們以滿足你的要求。其實,已經有大量能夠獲得的第三方開發模型,如Scrum and process MeNtOR。
訪問工作項目儲存空間
建立了Team 專案後,開發小組須要做的第一件事是分解已經建立的初始工作項目集。這些工作項目協助開發人員完畢一系列能夠使得軟體項目成功開始的活動,而且根據不同的開發模型選擇不同的工作項目。通過展開Team 專案節點,就能夠看到工作項目錄,繼續展開然後開啟查詢目錄可看到所有或部分工作項目。
書寫定製得工作項目查詢
最後須要書寫一個新的工作項目查詢列表。新定義的查詢能夠放在“團隊查詢”和“我的查詢”這兩個目錄的不論什麼一個。團隊查詢是一個可被項目小組中的全部開發人員訪問的全域可訪問容器,我的查詢是一個由每一個程式開發員全部的私人查詢集。
我常常使用的一個實用的查詢是Recycle Bin query,這個查詢可用於開啟近期關閉又須要又一次開啟的工作項目(偶然關閉工作項目的情況時有發生)。第一步是從工作項目節點的背景菜單中選擇“加入?查詢”。
在查詢編輯器開啟後,簡單的使用者介面就能夠基於某些簡單的運算式從工作項目列表中過濾出須要的項目。在上面的情況中,查詢設定為返回目前狀態為關閉的Team 專案中的全部工作項目。
應用Team Foundation Server的版本號碼控制
訪問了工作項目,就能夠應用Team Foundation Server中的版本號碼控制。像TFS中的其他特徵一樣,版本號碼控制功能位於SQL Server 2005之上,用於提供良好的效能和可擴充性(實際上,宿主在TFS中的版本號碼控制儲存空間的大小預計有千MB。開發小組可能遇到的第一個與版本號碼控制相關的工作項目是遷移已經存在的源碼,這個工作項目提供了在遷移源碼是須要做什麼的具體視圖。
配置一個工作區
在程式猿將檔案加入?到版本號碼控制儲存空間之前,須要將版本號碼控制儲存空間的邏輯結構映射到本地機器上的檔案系統。Team Foundation Server 引入了工作區的概念。工作區是物理位置和檔案系統間的一組映射,一個檔案系統與一個特殊使用者和電腦群組合相匹配。在檔案上進行工作的程式猿,他們是邏輯的進出工作區。為了建立一個工作區,程式猿須要雙擊Team Explorer中的原始碼控製圖標,到工作區下拉式功能表。
我發現將整個源碼樹的根映射到本地磁碟機上的一個詳細位置並將其作為唯一映射是最簡單的方法。我自己的方法是在我的資料磁碟機的根資料夾上建立一個“沙箱”檔案夾,在它的下級有一個子檔案夾,將其命名為我串連到的TFSserver的名字。(我串連到了多個TFSserver,因此一定要注意避免混淆)。
建立了映射之後,瀏覽源碼控制瀏覽器將會列出源碼樹上邏輯位置的本地路徑。至此你就能夠加入?源碼到這個容器中。
程式猿面對的一個局限是他們不能將檔案加入?到版本號碼控制儲存空間的根中($/),且全部以及目錄都直接和某個特定Team 專案相關。這裡面的邏輯是,一個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)實施軟體組態管理可以有效解決這些問題,比如可以集中管理各項目的文檔、代碼,對項目中的文檔、代碼等的變化進行有效管理,可以方便地重現某個檔案的曆史版本號碼,可以又一次編譯某個曆史版本號碼,使文檔維護工作變得easy、可以使多團隊並行開發成為現實,同一時候實行統一的組態管理流程可提高項目組間人員流動時的工作效率,也是對工作成果的一種有效保護。
功能介紹二:外包管理工具
隨著資訊技術的飛速發展,軟體已進入了社會生活的方方面面,越來越多的企業將他們的業務系統構建在以軟體為核心的系統之上,企業通過它們來為自己的客戶提供高速優質的服務。正由於軟體已經成為業務的基礎平台,企業的核心競爭力在非常大程度上取決於軟體系統的品質,要求軟體系統可以迅速適應業務需求的變化,同一時候保證軟體系統的高效能、高可靠性和可維護性。然而對於大部分企業而言,軟體開發並非他們所擅長的業務,加上軟體系統的複雜性及非常高的品質要求,大部分企業都選擇將軟體開發項目外包出去,由專業的軟體開發(供應)商來負責軟體的開發。可是軟體外包並不意味著企業對於軟體的開發過程放手無論,企業應該建立與供應商之間的協議,而且監控供應商的開發過程,並對供應商提交的終於系統進行全面的驗收,從而徹底保證供應商可以按時交付一個高品質的軟體系統。軟體項目的成敗在非常大程度上取決於對其開發過程的控制,這包含對品質、源碼、進度、資金、人員等的控制。要進行有效過程式控制制,只依靠人的力量是不夠的,還須要有對應的管理工具支援以實現高效的“軟體生命週期管理”。然而因為曆史和現實的原因,軟體生命週期管理流程和工具在我國軟體行業中的應用並不普及,因為缺乏必要的管理流程和工具,非常多企業在軟體外包項目中都會或多或少的遇到例如以下的問題:l
缺少統一的開發管理流程指導,無法保證項目的品質和成功率l
開發出來的系統不能滿足使用者或者業務需求l
開發過程不透明,非常難監控開發的進展情況l
不能及時瞭解項目的
進度,常常導致項目延期l
無法有效控制項目的變更,添加?了項目的風險l
無法有效實現多地的協同開發
,添加?外包開發成本(場地,差旅費)l
軟體複用率低下,減少了企業的投資報酬率l
無法開展正常化的測試工作
,非常多問題要到驗收階段才會暴露出來l
缺乏軟體開發曆史資料的積累,
無法準確估算項目成本l
缺乏必要的版本號碼管理工具,系統在構建和公布時產生問題l
缺乏對應的文檔,添加?了維護和升級的難度 這些問題導致非常多企業對外包項目不能進行有效控制或是在開發中造成過多的資源浪費(各個系統間太多的反覆開發),以及開發出來的系統不能響應市場高速的變化。這些問題直接減少了發包方企業的生產力,添加?了企業運營成本。要從根本上切實提高軟體外包開發的管理水平,必須從多方面入手,引入先進的開發流程,借鑒業界的最佳實務,以及構築高效的系統開發管理平台是必定的選擇。為瞭解決上述的外包開發管理中的常見問題,我們基於微軟最新公布的軟體生命週期工具,設計了微軟的軟體外包開發管理解決方式,可以對多平台和地理分布的Team Dev提供必要的開發流程指導,實現高效的專案管理,促進項目團隊的溝通,並提供了緊密整合的變更和組態管理系統,為企業建立了先進的軟體協同開發管理平台。