在 tfs 2010 团队项目创建期间是否可以选择指向现有门户网站而不是创建新网站?

发布于 2024-10-20 23:23:57 字数 434 浏览 2 评论 0原文

我们是一个小团队,考虑从 Source Safe 迁移到 TFS 2010,以获得更丰富的 ALM 可能性,而不仅仅是更好的版本控制。我们打算从工作项目、任务、门户等中受益。TFS

2010 的设计似乎是为了在团队项目和 WSS 门户站点之间存在一对一的关系。是否有可能让一个 WSS 门户(在我的例子中为 v3.0)与多个团队项目指向它?

一本写得很好的书,即“Professional ALM with VS2010 (Wrox 2010)”,在第 526 页第 22 章中指出,“如您所见,有一个选项可以指向现有网站而不是新的门户网站”。但该图显示的对话框页面可能与早期测试版不同。

我担心的是,对于像我们这样少于 10 人的小团队来说,单个团队门户足以满足同时活跃的多个项目。

我应该选择一个{团队项目 + WSS 项目门户}并为多个不同的产品使用区域/迭代吗?您有哪些相关经验?

We are a small team considering moving to TFS 2010 from Source Safe for richer ALM possibilities rather than just better version control. We intend to benefit from the work items, tasks, portal etc.

It seems to be that TFS 2010 is designed so that there is a one to one relationship between Team Projects and WSS Portal Sites. Is it somehow possible to have a single WSS Portal (v3.0 in my case) with multiple team projects pointing to it?

A well written book, namely "Professional ALM with VS2010 (Wrox 2010)", states on page 526 Chapter 22 that "As you can see, there is an option to point to an existing Web site instead of a new portal site". But the figure shows a different dialog page from an earlier beta possibly.

My concern is that, for a small team of less than 10 people like ours, a single Team Portal would be sufficent for the several projects active at any one time.

Should I go for a single {Team Project + WSS Project Portal} and use areas/iterations for the several different products? What are your relevant experiences?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

我恋#小黄人 2024-10-27 23:23:57
  1. 在团队项目创建向导过程中,您无法指向现有站点。
  2. 团队项目的粒度确实可以是每个项目,也可以是更高级别(组织/部门/...)。将会有人支持其中一种选择,也有人支持另一种选择。在我看来,这取决于项目的相关程度。如果他们共享相同的代码库、相同的文档或发布时间表,则使用一个团队项目。如果是完全不同的产品/应用程序,则使用多个团队项目。

那只是我的2分钱。

  1. You cannot point to an existing site during the team project creation wizard
  2. The granularity of team projects can be indeed per project, or it can be on a higher level (organization / department / ...). There will be advocates for the one and for the other option. In my opinion it depends how related the projects are. If they share the same code base, same documentation or release schedule, then use one team project. If it are totally different products / applications, then use multiple team projects.

That are just my 2 cents.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文