2008-12-30 74 views
8

我們的小型開發商正在尋求將我們的項目從VSS遷移到TFS,並且我們正在評估TFS與其他項目(還沒有拉動觸發器)。我們軟件商店的性質使我們擁有100多個VSS項目,從小型單人展示項目到大型企業級應用程序。TFS結構 - 多個項目還是單個項目?

我們正試圖確定如何構建我們的項目過渡,並有,在大多數情況下,決定把一切都變成一個項目網站/系統,每個項目有落根的子文件夾。

使用這種類型的設置,我們擔心我們將失去TFS提供的許多功能(bug跟蹤,scrum消失,報告,文檔存儲等),因爲所有項目都將位於同一個入口/項目空間,將很難分離出單個項目的門票/項目。

有沒有人有這方面的經驗?你的解決方案是什麼?你堅持使用TFS嗎?

回答

6

回答這個問題需要你做一些規劃:你打算如何使用TFS,以及哪些功能在產品固有的侷限性。我會總結我的建議爲:

  1. 您將需要每個流程模板至少1個團隊項目。也就是說,如果兩個團隊想要採用/定製不同的流程,他們需要分開。

  2. 一旦滿足條件#1,您可能不需要像您想象的那樣多的單獨的團隊項目。 90%的TFS功能&設置本質上是分層的,允許您根據每個項目的要求將它們限定爲廣泛或狹義。

完整的詳細信息,請參閱:

2

這是事實,以爭取所有的TFS的好處,最好使用單獨的項目,但這些益處應該對管理有很多項目的管理成本進行權衡。多年前,我使用Visual Source Safe ...在離開微軟之後,我切換到了Subversion。回到微軟之後,我使用了TFS,到目前爲止我對此非常滿意。

流程指導,報告,集成錯誤跟蹤和嚴密的IDE集成完美地滿足了我的需求。另外,TFS SDK允許一些有趣的可擴展場景。

1

我用幾個SCC提供商,我們已經爲所有的有別人所沒有的功能上TFS解決。錯誤關聯,CI和自動化測試當然在優勢列表中名列前茅。

至於是否使用多個項目或沒有,我會說這取決於如果項目共享任何共同的代碼。我們傾向於對所有「相關」代碼資產使用TFS項目,因此如果我們有幾種不同的解決方案可以做類似的事情並共享大量代碼,那麼我們使用單個TFS項目。如果他們沒有共同之處,那麼他們就成爲單獨的項目。

0

我不確定這是否在2008年得到了修復,但在2005年,當您構建一個項目是一個根項目的子文件夾時,MSBuild將拉動根項目的整個源代碼樹 - 即使不屬於你的子文件夾。

取決於您管理的源數量,這可以大大增加您的構建時間。

2

我採取的方法是有一個TFS項目組件中的每個邏輯分組 - 所以我們包含常見的組件,我們所有的applicaitons一個框架項目,然後我們有一個單獨的項目對我們的報價系統,成本系統的另一個等等。雖然工作空間映射有點「有趣」,但它確實允許不同項目的不同設計方法以及不同的時間尺度 - 因此,一個團隊可能在衝刺中途(大多數項目使用Scrum for Team System),同時又是另一個剛剛開始......

0

我知道這篇文章是舊的,但TFS 2010現在支持一個奇妙的功能調用團隊項目集合,這只是另一個級別的indir在項目之上進行排列或分組。

這使得創建團隊項目更容易,而不會堵塞你的名字空間,並鼓勵更好的組織!

偉大的鏈接更多地談論集合

http://blogs.msdn.com/b/bharry/archive/2009/04/19/team-foundation-server-2010-key-concepts.aspx

我一個不是SharePoint用戶,但我聽到它非常相似的概念到SharePoint收藏:)