2008-12-30 62 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收藏:)