2

在我们当前的 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.

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

4

2 回答 2

2

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

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

在此处输入图像描述

于 2013-03-01T11:38:28.097 回答
1

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

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

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

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

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

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

于 2013-03-01T16:17:56.870 回答