TFS 2010集合文件夹结构

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

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

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

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

来源

2013-03-01 Matei

下面是如何为每个项目使用“主模型”以及如何处理项目间依赖关系的示例：http://stackoverflow.com/a/9846068/600559 – 2013-03-01 17:35:19

感谢您提供有用的评论。对于依赖关系来说这是一个有趣的策略，但是我们将坚持一个扁平结构，因为我们的依赖关系有时会达到3或4级。我们只有很少的.DLL依赖关系，并且我们保留在源代码管理的存储库中，只是在需要时手动更新。 – Matei 2013-03-05 08:49:35

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

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

enter image description here

来源

2013-03-01 11:38:28 slugster

我与团队的其他成员一起完成了选项，我们将为第一个选项做好准备。其中一个原因是保持整洁，另一个原因是因为我们的服务规模较大，未来可能需要不同的分支策略，而不仅仅是Dev和Main。所以我们试图保持我们的选择对于分支以及时间的推移。 – Matei 2013-03-05 08:47:08

答案分支结构的问题取决于你如何规划你的版本。

如果你发现你几乎总是释放每次1个服务和其他服务是从一个独立发展的又一个，然后去选择1

如果你更有可能在被不断变化的多种服务同一时间，并将它们放在一起，然后我会选择2.

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

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

至于关于构建的问题，不要担心，无论你选择哪种布置策略，你的构建都可以。不过，我想说的是，从经验来看，拥有在单个分支中构建所需的所有解决方案/依赖关系将会使生活更加容易。

来源

2013-03-01 16:17:56

TFS 2010集合文件夹结构

回答

相关问题