我应该如何根据我的现实情况配置 TFS 团队项目？
我们有一个项目将在未来 12 至 18 个月内分多个阶段开发。这是瀑布环境中的敏捷式项目，这一点很重要。
我最初的想法是创建一个名为“Project X”的团队项目。 Project X 下可能有多个解决方案文件夹，但主要开发内容将位于名为 Main 的文件夹中。将酌情进行分支。
Project X 团队项目下的其他解决方案文件夹将用于存放我们需要为此项目构建的一些工具，这些工具独立于主应用程序（一个 Web 应用程序）。例如，我们需要构建一个应用程序来处理数据并将其发送到 Web 服务，但它从未以任何方式与主 Web 应用程序交互或合并。
我认为这种方法的优点是 a) 项目的所有代码都保存在单个团队项目下，b) 所有工作项、错误、愿望清单项都可以从所有其他项目访问。
这种方法有意义吗？有什么想法可以改进这个吗？我还没有创建团队项目。
We have a project that will be developed in multiple phases over the next 12- 18 months. It's an agile-esque project in a waterfall environment, it that matters.
My initial thought was to create one team project named 'Project X'. Under Project X could be multiple solution folders but the main development would be in a folder called Main. Branching would be done as appropriate.
The other solution folders under the Project X team project would be for some of the tools we need to build for this project that are independ of the main app, which is a web app. For example, we needed to build an app for processing data and sending it to a web service but it never interacted or merged in any way with the main web app.
The advantages I see to this approach are a) all the code for the project is kept under a single team project and b) all the work items, bugs, wishlist items, are accessible from all the other projects.
Does this approach make sense? Any ideas to improve this? I haven't created the team project yet.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我将简单地评论您列出的优点，以帮助您理解为什么这种方法并不理想。
您的工具和 Web 应用程序都适用于“此项目”。右边有一个关键指标，表明您应该在 TFS 中使用一个团队项目。拥有两个独立的团队项目不会给你带来任何好处。事实上，您可能会使管理变得更加困难。
考虑一下您是否有一项需要既需要工具又需要主应用程序来完成的工作。在您的场景中，由于您正在使用两个团队项目，因此无法跟踪与一项需求相关的工作历史记录。还有很多原因，您必须在两个地方管理权限，有两组映射等。
我强烈建议您选择使用一个团队项目。您和您的整个团队稍后都会感谢我。
如果您有两个团队项目，则无法跨项目访问 WI 等。事实上，情况恰恰相反——如果两个项目之间的工作交叉，您将必须在两个项目中创建 WI。
您应该有一个团队项目。工具文件夹和 Web 应用程序文件夹。从那里你可以进一步将其分支出来——一个用于开发的分支和一个用于主干的分支是一个好的开始。每个内部都有工具和 Web 应用程序，以便版本保持同步。
在设置项目之前，这里是开始阅读的好地方：Microsoft Team Foundation Server 分支指南。
I will simply comment on the advantages you listed to help you understand why this approach isn't ideal.
Both your tools and your web application are for "This project." That right there is a key indicator that you should use one Team Project inside of TFS. You gain nothing by having two separate Team Projects. In fact, you may make it more difficult to manage.
Consider if you have a requirement that has work one both a tool and the main application to complete. In your scenario, there would be no way to track work history associated to one requirement because you are using two Team Projects. There are many more reasons, you have to manage permissions in two places, have two sets of mappings etc etc.
I would highly recommend you opt to use one Team Project. You, and your entire team, will thank me later.
If you have two Team Projects, you cannot access WIs etc across the projects. In fact, you will have the exact opposite- you will have to create the WIs in both projects if the work crossed over between the two.
You should have one Team Project. A folder for the tools and a folder for the web application. From there you can take it further having it branched off- a branch for development and a branch for main is a good start. Inside each, have the tools and web application so the versions stay in sync.
Here is a good place to start reading before setting up your project: Microsoft Team Foundation Server Branching Guidance.
您所描述的不是团队项目。您只是描述了 TFS 中某些源代码管理文件夹的结构。
团队项目不仅仅是源代码控制。来自 T（Visual Studio ALM 术语表）：
What you're describing is not a Team Project. You're simply describing the structure of some source control folders in TFS.
A Team Project is a lot more than just source control. From T (Visual Studio ALM Glossary):