我使用TFS和RM在过去2 . 5年（也是使用rm 13）创建了构建版本 .
最近，我试图在我们公司中嵌入分支策略的'Branching by Quality'模式 . 我们需要在我们的开发过程中进行热修复合并，sprint合并，bug修复合并 . Branching by Quality Pattern这是一个小例子：
我们可以同意在 生产环境 之前将热修复程序上传到测试环境会将qa当前正在测试的所有新功能与我们想要的小型紧急热修复混合在一起，因此代码很脏 . 与聪明人坐在一起，我们几乎想出了这种模式，所以当我偶然发现这种模式时，我认为它将与我们非常相配，并且对于我们的持续部署和集成，因为合并到每个分支（main \ dev，test， prod）去了正确的环境，分支是稳定和永久的，并没有从我的部门（devops）的维护努力 . 我们只在这些分支上添加更多构建和版本，以便我们想要自动化更多应用程序 .
一家外部咨询公司为我们提供咨询，并且正在推广Scrum，还有另外一件事 . 我无法理解动机，所以也许有人可以协助或反驳我或顾问在我们的案例中提供的内容（不是竞争，只是试图将解决方案附加到我公司的现实生活中） . 他发送了以下网址：Branching strategies with TFVC
其次是另一个参考：
Effective TFVC branching strategies for DevOps
简而言之 - 我们提供了在新分支上创建 v1.0 和我们的发布管道（ci cd） . 这将始终改变，我们将在每个版本上更改管道（ v2.0 , v50.0 等等） .
我经历了很多文章，说功能分支策略在持续集成方面效果不佳 - 很明显，发布Isolation建议每个版本都在一个新的分支上，类似于功能分支，我们应该希望发布将持续2 -3周最多将它合并到主分支 . 我只是看不出它是如何自动化的，它如何支持热修复自动化（热修复前一个分支将使我们改变所有构建以与该分支一起工作）并且我将展示我的意思 .
我正在使用TFS 2015 with Release Management来执行持续集成构建，并在Windows上发布所有代码.Net . 因此，我们有一个分支用于连续集成，并在其上有触发器 . 我想提一下，在我的公司，我们有超过30个（并且不断增加）的服务构建和发布，我们有200多个应用程序，所以我们自动化最紧急的应用程序，我们努力实现越来越多的自动化 .
我在上面添加的链接（顾问共享它们）中提供的解决方案是每次有新版本（每2-3周在scrum中工作）创建一个发布管道，请注意在TFS Build中，有一个特定的分支引用应该构建（源和触发器），这意味着每个版本我们将不得不将源和触发器中的所有分支名称和主sln \ csproj更改为发布分支的名称（例如r12） . 这将因项目而异，因为并非所有项目都具有相同的发布分支名称（例如，某些项目将为r5 \ r20），因此您不能仅自动覆盖每个不同应用程序的构建的分支名称 .
虽然它被写成好像这种分支策略支持tfvc用于devops和持续交付，但它似乎是一项艰巨的冗余任务，为我们所有的自动化应用程序EACH RELEASE改变发布分支名称 . 这似乎是一个非常多的不必要的工作，没有明显的优势 - 当然是 to me . 该顾问相信他的解决方案更好更先进，Visual Studio网站在同一篇文章中使用'Continuous'这个词时显示了这个解决方案！另外，我们的部门很小，手上有很多其他的东西，任何人都可以帮我看看我没看到的东西吗？
这是我们在每个版本中必须要做的变化过程：
请注意，触发器在tfs 2015版本中不可复制 .
请注意，我想请求一个优雅的，不是黑客的，证明工作（即使在理论上，这很好）的解决方案，如果这意味着我们必须编写一个变通方法，它被认为是从我的经验中增加一个失败点和维护点 .
谢谢 ！
1 回答
你的问题太过分了，可能有点主观 . 没有共同商定的分支策略适用于任何项目大多数资源似乎都同意选择 生产环境 策略取决于 particular project specifics side note.
根据这一点，看起来项目分支策略的任何变化都需要 tested, measured and compared to other options tested .
您没有提到这么清楚如何在第一个解决方案中处理发布 . 生产环境 版本是否来自主干/主要或分支 . 根据大多数其他人的经验谷歌：
此外，关于修补程序和您的顾问共享自动化 . 通常我们在“功能完成”时创建发布分支，并计划在此代码行上修复最后一分钟的问题 . 正如上面的教程和屏幕截图所示，当您需要为已发布的代码创建错误修复时，看起来该过程正在分支发布 . 在这种情况下，可能不需要修复每个先前的分支 .