跨团队项目的 TFS 2010 分支 - 最佳实践 [英] TFS 2010 Branch Across Team Projects - Best Practices

问题描述

我在理解如何根据 TFS Ranger 团队提供的最佳实践配置 TFS 时遇到问题.问题是这样的:

I'm having issues understanding how to configure TFS according to best practices as provided by the TFS Ranger team. The issue is such:

我公司有几种产品使用共享的公共代码库.

My company has several products which make use of a shared common code base.

> $/Core
>  -> /Main/Source (Parent Branch)
> 
> $/Product1
>  -> /Main/Source
>  -> /Main/Source/Core/Source (Child Branch from $/Core)
>  -> /Main/Source/...
> 
> $/Product2
>  -> /Main/Source
>  -> /Main/Source/Core/Source (Child Branch from $/Core)
>  -> /Main/Source/...

因此，对于此示例，我们有一个团队集合，比如说，三个团队项目.($/* 是一个团队项目)

Therefore we have one team collection and say, three team projects for this example. ($/* is a team project)

我们最初的发布分支有点痛苦.我们没有在/Main 到/Releases 或/Main 到/Development 上进行分支，而是单独对每个项目进行了分支.(不是团队项目...解决方案项目.)

Our initial release branching is a bit of a pain. Instead of branching on the /Main to /Releases, or /Main to /Development, we have been branching each project individually. (Not team project ... solution project.)

这是由于无法嵌套分支根.(参见 TFS 错误:TF203028 和 TF203071)

This is due to the inability to have nested branch roots. (See TFS Errors: TF203028 and TF203071)

根据 TFS Ranger Guide 和我们修订后的分支发布、修补程序、开发方法，我们应该从/Main 而不是/Main/Source/Proj1、/Proj2、/Proj3 等分支.这只是一个相当大的烦恼.

According to TFS Ranger Guide and our revised approach to branching releases, hotfixes, developments, we should branch from /Main rather than /Main/Source/Proj1,/Proj2,/Proj3, etc. It's just become a rather large annoyance.

理想情况下，我们希望:

Ideally we would like:

> $/Product1
> -> /Main/ (Branch - Parent)
> -> /Releases
>    -> /1.x
>       /1 Service Pack (Child Branch from $/Product1/Main
>       -> /1.0
>          -> /1.0 Hotfix (Child Branch from $/Product1/Releases/1.x/1 Service Pack)
>          -> /1.0 RTM (Child Branch from $/Product1/Releases/1.x/1.0/1.0 Hotfix - Read Only)
>          -> /1.0.22 RTM (Child Branch from $/Product1/Releases/1.x/1.0/1.0 Hotfix - Read Only)
>       -> /1.5
>          -> /1.5 Hotfix (Child Branch from $/Product1/Releases/1.x/1 Service Pack)
>          -> /1.5 RTM (Child Branch from $/Product1/Releases/1.x/1.5/1.5 Hotfix - Read Only)

解决方案:1. 我们可以将每个共享分支(即 $/Core)转换回常规文件夹.这样/Main 下的任何文件夹都不是分支根.然后我们可以执行从 $/Product1/Main/Source/Core/Source 返回到父 $/Core/Source 的 baseless 合并.

Solutions: 1. We can convert each shared branch (ie. $/Core) back to regular folders. This way no folder under /Main is a branch root. We can then perform a baseless merge from $/Product1/Main/Source/Core/Source back to the parent $/Core/Source.

有没有人有过毫无根据的合并的经验.我从微软那里读到的是，它们是不应该司空见惯的例外.MS 表示，如果您使用 TFS 正确设置您的项目，您将永远不需要执行 baseless 合并.

Has anyone any experience with baseless merges. What I've read from Microsoft is that they are exceptions which should not be commonplace. MS states that if you set up your projects properly with TFS, you would never need to perform a baseless merge.

当跨团队项目分支时，这怎么可能?！?在任何软件开发公司中，在产品之间共享库应该是司空见惯的.

How is this possible when branching across team projects?!? It should be commonplace in any software development house to have shared libraries amongst products.

我也愿意接受其他解决方案.

I'm open to other solutions too.

谢谢！

推荐答案

我会在环中添加一个选项，它可能对您有用也可能没有用.如果有什么安慰的话，我已经考虑了一段时间，但一直无法提出一个完全令人满意的解决方案.这是一个非常好的问题，我很想知道其他人是如何解决这个问题的.

I'll throw an option in to the ring, it may or may not not be useful to you. If it's any consolation I've been pondering over this one for a while now and haven't been able to come up with a completely satisfactory solution. It's a really good question and I'd be very interested in seeing how others have solved this problem.

我知道尽可能从源代码构建被认为是一个好主意，但我不喜欢在团队项目之间进行分支.如果您有一些通用代码并且需要在 2 或 3 个其他团队项目之间进行分支，那么分支是可以管理的，但如果您有 20 或 30(或 100)个团队项目，那么管理合并就变得令人头疼.如果在消费团队项目中工作的开发人员在主"中没有相同的权限，例如无法查看历史记录等，则可能会出现其他问题.当然，如果您有需要在团队项目之间共享的代码在不同的项目集合中，无论如何你都不能分支.

I know it's considered a good idea to build from source wherever possible but I'm not a fan of branching between Team Projects. If you have a some common code and it needs to be branched between 2 or 3 other Team Projects then the branching is manageable but if you have 20 or 30 (or 100) Team Projects then managing the merges becomes a headache. There can be other issues if the developers working in the consuming Team Projects don't have the same permissions in the "master" such as not being able to see history etc. Of course if you have code that needs to be shared between Team Projects in different Project Collections then you can't branch anyway.

因此，考虑到这一点，我建议您像对待 3rd 方库和使用二进制引用一样对待公共代码.一旦您进入这种思维模式，您就可以使用多种选择.(这里有一些，但可能还有更多)

So with that in mind I would suggest that you treat the common code in the same way you might treat a 3rd party library and use binary references. Once you get in to that mindset a number of options are available to you. (here are a few but there are probably more)

1. 您可以让公共代码的构建将二进制文件复制到放置位置，以及用于打包的合并模块(如果您使用 MSI).然后创建一个对放置位置的二进制引用，并获取用于打包导入合并模块的任何内容.在这种情况下，您需要确保放置位置稳定(并且最好只对大多数开发人员读取以防止篡改)
2. 类似于选项 1，但使用像 NuGet 之类的工具来管理您的引用，这将自动执行该过程引用新版本的二进制文件.
3. 您可以将二进制文件签入您分支中的 $/Product1/branch/lib/common 文件夹，并使用相对路径引用它们

1. You could have the build for your common code copy the binaries to a drop location, alongside a merge module for packaging (if you use MSI). You then create a binary reference to the drop location and get whatever you use for packaging to import the merge module. In this scenario you need to make sure that the drop location is stable (and preferably read only to most of the devs to prevent tampering)
2. Similar to option 1 but use a tool like NuGet to manage your references, this will automate the process of referencing new versions of the binaries.
3. You could just check in the binaries to $/Product1/branch/lib/common folder in your branch and reference them using a relative path

正如我所说，我很想听听其他 SO 人员如何使用 TFS 解决共享代码问题.

As I said, I'm very interested in hearing how other SOers have solved the shared code problem using TFS.

经过 8 年的思考，Nuget 包是这里的前进方向.我已经将其余的答案留在原处，因为它仍然可以获得观点和投票.将依赖项构建到包中并将它们存储在二进制存储库(nuget/Nexus/Artifactory/Azure Artifacts 等)中几乎是解决此问题的标准方法

After 8 years of thinking about this, Nuget packages are the way forward here. I've left the rest of the answer in place as it still gets views and up-votes. Building dependencies in to packages and storing them in a binary repository (nuget / Nexus / Artifactory / Azure Artifacts etc.) is pretty much the standard way of solving this problem

这篇关于跨团队项目的 TFS 2010 分支 - 最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！