TFS项目组织

发布于 2024-08-28 10:08:17 字数 86 浏览 5 评论 0原文

我对 TFS 比较陌生,想知道其他人在有很多项目的情况下如何组织 TFS​​?例如,有谁知道是否可以将 TFS 项目放入文件夹中,或者人们是否使用前缀/后缀?

I'm relatively new to TFS and am wondering other people deal with organising TFS where there are many projects? For example, does anyone know if it's possible to put TFS projects inside folders or do people use prefixes / suffixes?

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

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

发布评论

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

评论(3

清醇 2024-09-04 10:08:17

项目组织在很大程度上仍然是主观的,尽管这是我们在开始使用 Team Foundation Server 时都遇到的问题。 ALM 文档很有帮助,实际上我建议使用该文档的较新版本。您可以从 CodePlex 的 Visual Studio TFS 分支指南 2010 获取它。即使您不打算进行分支,如果您需要的话,能够这样做总是一个明智的主意。

使用较早的指南和这个较新的指南,我有一个用作样板的结构。我将向您展示仅包括“Main”分支的结构,如果您使用分支,您可以理解“Main”下的所有内容最终都会根据需要为每个分支进行复制。

$/Team Project Root
    /Main
        /Documentation
            /Project A
                {XML Help support - such as Sandcastle projects}
            /Project B
                {XML Help support - such as Sandcastle projects}
        /References
            {3rd party and scripts to install any the GAC, as/if needed}
        /Source
            /Project A
              {Project file, and associated source}
            /Project B
              {Project file, and associated source}
        /Tests
            /Project A
              {Project file, and associated source}
            /Project B
              {Project file, and associated source}
        {Solution Files}

这对我们很有帮助,并且可以作为指导方针。您必须准备好接受这样的事实:随着情况的变化以及您在组织内越来越多地使用该系统,您的需求也可能会发生变化。让我简单地处理 Main 下的每个顶级文件夹:

  • 文档 - 我倾向于经常使用 Sandcastle Help File Builder,并将文档项目提升到层次结构中自己的级别,例如源代码和文档

  • 参考资料 - 我看到人们对于程序集是否属于 Team Foundation Server 内部的争论持有激烈的争论。我曾经反对,但发现这个文件夹结构不会经常改变,相关的项目经常共享相当数量的相同引用,并且新的开发人员应该能够一次性获得他们需要的一切来启动项目并正在运行。

  • 来源 - 非常不言自明。相关项目,每个项目都存放在自己的文件夹中。文件夹以及项目均按其完整名称空间命名。

  • 测试 - 与源文件夹相同,但工件仅用于测试。通常,源中的“项目 A”在测试中具有相应的“项目 A”,并添加 .Tests 作为命名空间的一部分。

我将所有解决方案放在分支下,因此可以“一站式购物”到应用程序的多个视图中。我发现它可以避免始终在一个“大型解决方案”中工作。

至于分支,您可以根据需要添加它们,这样就不会不知所措。上面链接的指南在逐步引入分支方面做得非常好,我同意从简单的结构开始,然后根据需求进行构建的想法。我们使用的结构在生产项目中运行良好,也是我在个人项目中使用的结构。

Project organization is still largely subjective, although it is something that we all struggle with when starting with Team Foundation Server. The ALM documentation is helpful, and there is actually a newer version of the documentation that I would recommend to draw upon. You can get it from the CodePlex at Visual Studio TFS Branching Guide 2010. Even if you do not plan on branching, it is always a wise idea to be in a position to do so, in the event that you need to.

Use the earlier guide, and this newer one, I have a structure that I use as a boilerplate. I will show you the structure just including the "Main" branch, and if you are use branching, you can understand that everything under "Main" will end up reproduced, as needed, for each.

$/Team Project Root
    /Main
        /Documentation
            /Project A
                {XML Help support - such as Sandcastle projects}
            /Project B
                {XML Help support - such as Sandcastle projects}
        /References
            {3rd party and scripts to install any the GAC, as/if needed}
        /Source
            /Project A
              {Project file, and associated source}
            /Project B
              {Project file, and associated source}
        /Tests
            /Project A
              {Project file, and associated source}
            /Project B
              {Project file, and associated source}
        {Solution Files}

This serves us well, and is meant to be a guideline. You have to be ready to accept that as things change and you use the system more and more within your organization, your needs may change, as well. Let me just tackle each of the top-level folders under Main, briefly:

  • Documentation - I have a tendency to use Sandcastle Help File Builder quite often, and have promoted documentation projects to their own level in the hierarchy, like source and tests are.

  • References - I have seen people be vehemently on both sides of the argument as to whether assemblies belong inside of Team Foundation Server. I used to be against, but find that this folder structure does not change often, related projects often share a fair number of the same references, and a new developer should be able to get everything that they need in one swoop to get the project up and running.

  • Source - Pretty self-explanatory. Related projects, each bucketed into their own folder. Folders, as well as projects, are named by their full namespace.

  • Tests - Same as the source folder, but artifacts solely for testing. Usually "Project A" in Source has a corresponding "Project A" in Tests, with the addition of a .Tests as a part of the namespace.

I put all of the solutions under the branch, so it is "one stop shopping" into multiple views into the application. I find it prevents having to always work in one "mega-solution".

As to the branching, you add them as you need them, so not to overwhelm. The guide, linked above, does a really good job of introducing branching gradually, and I agree with the idea to start with a simple structure, and build when the demand dictates. The structure we use works well in a production project, and is also the structure I use in my personal projects.

想念有你 2024-09-04 10:08:17

当我第一次开始使用 TFS 模式时实践:使用 Visual Studio Team Foundation Server 进行团队开发指南很有帮助。您可以将每个项目放在顶层,然后在它们下面有另一个用于主干和分支的文件夹。

$/Project1
 $/ProjectTrunk
 $/ProjectBranch
$/Project2
 $/ProjectTrunk
 $/ProjectBranch

这只是指南中众多示例之一。

When I was first getting started with TFS the Patterns & practices: Team Development with Visual Studio Team Foundation Server guide was helpful. You can put each project at a top level then underneath they have another folder for the trunk and branches for it.

$/Project1
 $/ProjectTrunk
 $/ProjectBranch
$/Project2
 $/ProjectTrunk
 $/ProjectBranch

This is just one example of the many that are in the guide.

樱花坊 2024-09-04 10:08:17

我们使用了一种扩展 .Net 命名空间层次结构的方法来指示相似的业务领域并将命名空间映射到文件夹结构。

命名空间:

Company.AreaA.Project1
Company.AreaA.Project2
Company.AreaB.Project3
Company.AreaB.Project4

文件夹:

$/Company/AreaA/Project1 
$/Company/AreaB/Project3

此约定也在项目中继续存在。

We have used an approach that extends .Net namespace hierarchy to indicate similar business areas and map the namespaces to the folder structure.

Namespaces:

Company.AreaA.Project1
Company.AreaA.Project2
Company.AreaB.Project3
Company.AreaB.Project4

Folders:

$/Company/AreaA/Project1 
$/Company/AreaB/Project3

This convention continues also within the projects too.

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