TFS 2010 集合文件夹结构答案

【问题标题】：TFS 2010 collection folder structureTFS 2010 集合文件夹结构
【发布时间】：2013-03-02 00:21:40
【问题描述】：

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

新集合具有以下格式（我们尽可能简单）：

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

目前只有几个项目采用这种方法（到目前为止效果很好），因此我们希望将所有剩余项目从旧集合移到新集合。

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

因为服务如此之多，并且考虑到将来我们希望通过门控签入等方式实现自动构建和部署，那么更明智的做法是什么？

这样构建服务：

-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.

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

【问题讨论】：

这是一个关于如何为每个项目使用“主模型”以及如何处理项目间依赖关系的示例：stackoverflow.com/a/9846068/600559
感谢您的有用评论。这是一个有趣的依赖策略，但是我们将坚持使用扁平结构，因为我们的依赖有时会达到 3 或 4 层。我们的 .DLL 依赖项非常少，而且我们保留在源代码控制的存储库中的依赖项只是在需要时手动更新。

标签： tfs

【解决方案1】：

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

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

【讨论】：

我与团队的其他成员一起检查了选项，我们将选择第一个选项。一个原因是保持整洁，另一个原因是我们有更大的服务，未来可能需要不同的分支策略，而不仅仅是 Dev 和 Main。因此，我们正努力在分支和时间流逝方面保持开放的选择。

【解决方案2】：

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

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

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

如果您不确定，或者您的版本可以混合使用，请选择选项 2。在分支中拥有您不打算更改的代码并没有真正的开销。

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

至于关于构建的问题，不要担心，无论您选择哪种策略，您的构建都可以。但是我会说，从经验来看，从长远来看，在单个分支中拥有构建所需的所有解决方案/依赖项将使生活更轻松。

【讨论】：