TFS 2010集合文件夹结构

Question

在我们目前的TFS环境中，我们有2个集合：让我们称它们为“新”和“旧”。旧集合是非结构化的，没有分支，它只被用作代码存储库。

新系列具有以下格式（我们保持尽可能简单）：

-NewCollection
    -Project Name
        -Dev (branch)
        -Main (branch)
        -Support (branch)

目前只有几个项目遵循这种方法（到目前为止一直运作良好），因此我们希望将所有剩余项目从旧集合移动到新集合。

这是问题所在。旧集合中的许多项目都是WCF服务（大约15或20个），它们包含业务逻辑的不同方面。我们的项目引用了这些服务，其中一些服务甚至相互引用。

因为有这么多服务，并且考虑到将来我们想要使用gated check-ins等实现自动构建和部署，哪些更明智？

构建这样的服务：

-NewCollection
    -Service 1
        -Dev (branch)
        -Main (branch)
        -Support (branch)
    -Service 2
        -Dev (branch)
        -Main (branch)
        -Support (branch)
    -Service 3
        -etc.

或者像这样：

-NewCollection
    -Services
        -Dev (branch)
            -Service 1
            -Service 2
            -Service 3
            -etc.
        -Main (branch)
            -Service 1
            -Service 2
            -Service 3
            -etc.

我问这个问题的原因是因为我不知道在配置构建时需要什么等等 - 我仍然在学习如何做到这一点我想在这样的情况下计划集合的结构在不久的将来配置自动构建/部署时，它不会使我们的生活复杂化。

Answer 1

我个人会使用您提到的第一个结构 - 在每个产品下保留分支。随着时间的推移，这将是一种更清洁的方法。

设置构建定义时，您需要指定属于GET操作的分支/工作区。如果保持文件系统布局与源代码控制布局相同，则只需引用每个服务使用者的相应服务接口，就像使用任何其他项目一样。这是一个例子 - 在这种情况下，我从我自己的解决方案中引用了Awesomium SDK：

Answer 2

分支结构问题的答案取决于您计划发布的方式。

如果您发现您几乎总是一次发布1项服务，并且其他服务的开发彼此分开，那么请选择选项1.

如果您更有可能同时更改多项服务并将它们一起发布，那么我会选择2。

如果您不确定，或者您的版本可以混合，那么请选择选项2.拥有您不打算在分支中更改的代码没有实际开销。

如果您选择选项1并且您打算一次更改2或3个服务，那么管理分支之间的所有合并将成为主要的开销。

关于构建的问题，不要担心，无论你选择什么样的策略，你的构建都可以。但是我会说，从经验来看，在一个分支中拥有构建所需的所有解决方案/依赖性将使生活更加轻松。