TFS 结构 - 多个项目还是单个项目？
我们的小型开发工作室正在寻求将我们的项目从 VSS 迁移到 TFS，并且我们正在评估 TFS 与其他方案（尚未启动）。 我们软件商店的性质是这样的，我们在 VSS 中拥有 100 多个项目，从小型的单人表演项目到大规模的企业级应用程序。
我们正在尝试确定如何在过渡过程中构建我们的项目，并且在大多数情况下，决定将所有内容放入一个项目站点/系统中，每个项目在根目录下都有一个子文件夹。
对于这种类型的设置，我们担心我们将失去 TFS 提供的许多功能（错误跟踪、scrum 燃尽、报告、文档存储等），因为所有项目都将位于同一门户/项目空间中，并且它将很难区分各个项目的门票/物品。
有人对此有经验吗？ 你的解决方案是什么？ 你坚持使用TFS吗？
Our small development shop is looking to migrate our projects from VSS to TFS, and we're evaluating TFS vs. others (haven't pulled the trigger quite yet). The nature of our software shop is such that we have 100+ projects in VSS ranging from small one-man-show projects to massive enterprise-wide applications.
We are trying to determine how to structure our projects in the transition and have, for the most part, decided on putting everything into one project site/system with each project having a subfolder off the root.
With this type of setup, we are concerned that we will lose a lot of the functionality that TFS provides (bug tracking, scrum burndowns, reporting, document storage etc.) because all the projects will be in the same portal/project space and it will be difficult to separate out individual project tickets/items.
Does anyone have experience with this? What was your solution? Did you stick with TFS?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
要回答这个问题，您需要进行一些规划：您打算如何使用 TFS，以及哪些功能在产品中具有固有的限制。 我将我的建议总结为：
每个流程模板[至少]需要 1 个团队项目。 也就是说，如果两个团队想要采用/自定义不同的流程，则需要将它们分开。
一旦满足条件#1，您可能不需要像您想象的那样多的单独团队项目。 90% 的 TFS 功能和功能 设置本质上是分层的，允许您根据每个项目的需要广泛或狭窄地设置它们的范围。
有关完整详细信息，请参阅：
The answer to this question requires some planning on your part: how you intend to use TFS, and which of those capabilities has inherent limitations in the product. I would summarize my advice as:
You will need [at least] 1 team project per process template. That is, if two teams want to adopt / customize different processes, they will need to be separated.
Once condition #1 is satisfied, you probably don't need as many separate Team Projects as you think. 90% of TFS features & settings are hierarchical in nature, allowing you to scope them as broadly or narrowly as each of your projects requires.
For complete details, see:
我采取的方法是为程序集的每个逻辑分组建立一个 TFS 项目 - 因此，我们有一个框架项目，其中包含所有应用程序通用的程序集，然后我们有一个用于报价系统的单独项目，另一个用于成本核算体系等。 虽然工作区映射有点“有趣”，但它确实允许不同的项目在不同的时间尺度上采用不同的设计方法——因此一个团队可能已经完成了冲刺的一半（大多数项目使用 Scrum for Team System），同时另一个刚刚开始......
The approach I've taken was to have a TFS project for each logical grouping of assemblies -- So we've a framework project that contains assemblies common to all our applicaitons, we then have a separate project for our quotations system, another for the costing system and so forth. Whilst the workspace mappings get a bit "interesting", it does allow different design methodologies for different projects, and at different timescales -- so one team might be half way through a sprint (Most projects use Scrum for Team System), at the same time as another is just starting...
确实，要获得 TFS 的所有优势，最好使用单独的项目，但应权衡这些优势与管理多个项目相关的管理开销。 几年前，我使用 Visual Source Safe...离开 Microsoft 后，我切换到 Subversion。 回到微软后，我正在使用TFS，到目前为止我对它非常满意。
流程指导、报告、集成的错误跟踪和紧密的 IDE 集成完美地满足了我的需求。 另外，TFS SDK 允许一些有趣的可扩展场景。
It is true that to garner all of the benefits of TFS, it is best to use separate projects, but those benefits should be weighed against the administrative overhead associated with managing many projects. Years ago, I used Visual Source Safe...After I left Microsoft, I switched to Subversion. After returning to Microsoft, I am using TFS and so far I am very happy with it.
The process guidance, the reports, the integrated bugtracking, and the tight IDE integration serve my needs perfectly. Plus, the TFS SDK allows for some interesting extensibiilty scenarios.
我使用过多个 SCC 提供商，并且我们选择了 TFS，因为它具有其他提供商没有的所有功能。 Bug 关联、CI 和自动化测试无疑位居优势榜首。
至于是否使用多个项目，我想说这取决于项目是否共享任何公共代码。 我们倾向于对所有“相关”代码资产使用 TFS 项目，因此，如果我们有多个执行类似操作并共享大量代码的不同解决方案，我们将使用单个 TFS 项目。 如果它们没有任何共同点，那么它们就会成为单独的项目。
I've used several SCC providers and we've settled on TFS for all of the features it has that others don't. Bug correlation, CI and automated testing certainly topped the list of benefits.
As for whether you use multiple project or not, I'd say it depends on if the projects share any common code. We tend to use a TFS project for all "related" code assets, so if we have several different solutions that do similar things and share a lot of code, we use a single TFS project. If they have nothing in common, then they become separate projects.
我不确定这个问题是否在 2008 年得到修复，但在 2005 年，当您构建一个作为根项目的子文件夹的项目时，MSBuild 将提取根项目的整个源代码树 - 甚至不属于您的子文件夹的文件。
根据您管理的源数量，这可以大大增加您的构建时间。
I am not sure if this was fixed in 2008 but in 2005 when you built a project that was a subfolder of a root project, MSBuild will pull the entire source tree of the root project - even files that are not part of your subfolder.
Depending on how much source you are managing this can greatly increase your build times.
我意识到这篇文章已经过时了，但 TFS 2010 现在支持一项出色的功能，称为“团队项目集合”，这只是项目之上的另一个间接或分组级别。
这使得创建团队项目变得更加容易，而不会堵塞您的命名空间，并鼓励更好的组织！
详细讨论集合的精彩链接
http://blogs.msdn.com/b/bharry/archive/2009/04/19/team-foundation-server-2010-key-concepts.aspx
我不是 sharepoint 用户，但我听听它与 Sharepoint 集合非常相似的概念:)
I realize this article is old, but TFS 2010 now supports a wonderful feature call Team Project Collections which is simply another level of indirection or grouping on top of Projects.
This makes it much easier to create Team Projects without clogging up your namespace and encourages better organization!
Great Link talking more about Collections
http://blogs.msdn.com/b/bharry/archive/2009/04/19/team-foundation-server-2010-key-concepts.aspx
I a not a sharepoint user but I hear its very similar concept to Sharepoint collections :)