TFS项目组织

Question

我对TFS比较新,我想知道其他人在组织有很多项目的TFS吗？例如,有人知道是否可以将TFS项目放在文件夹中或者人们使用前缀/后缀？

Answer 1

项目组织在很大程度上仍然是主观的,尽管从Team Foundation Server开始,我们都在努力解决这个问题.ALM文档很有帮助,实际上我建议使用更新版本的文档.您可以从Visual Studio TFS分支指南2010中的CodePlex获取它.即使您不打算进行分支,如果您需要,最好能够做到这一点.

使用早期的指南,这个更新的指南,我有一个结构,我用作样板.我将向您展示刚刚包含"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帮助文件生成器,并且已经将文档项目提升到层次结构中的各个级别,例如源和测试.

• 参考资料 - 我已经看到人们在论证的两个方面都强烈关于程序集是否属于Team Foundation Server.我曾经反对,但发现这个文件夹结构不经常更改,相关项目通常共享相同数量的相同引用,并且新开​​发人员应该能够一举获得他们需要的所有东西以获得项目并运行.

• 来源 - 相当不言自明.相关项目,每个都分成自己的文件夹.文件夹和项目以其完整名称空间命名.

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

我将所有解决方案都放在了分支机构下面,因此它可以"一站式购物"到应用程序的多个视图中.我发现它可以防止必须始终在一个"超级解决方案"中工作.

至于分支,你可以根据需要添加它们,所以不要压倒.上面链接的指南非常好地逐步引入分支,我同意这个想法从一个简单的结构开始,并在需求指示时构建.我们使用的结构在生产项目中运行良好,也是我在个人项目中使用的结构.