在过去的 2.5 年里，我一直在使用 TFS 和 RM 创建构建和发布（也使用 rm 13）。
最近，我尝试在我们公司的分支战略中嵌入“质量分支”模式。我们在开发过程中需要热修复合并、冲刺合并、错误修复合并。按质量模式分支这是一个小例子：
我们可以同意，在生产之前将热修复上传到测试环境会将质量检查当前正在测试的所有新功能与我们想要的小型紧急热修复混合在一起，因此代码很脏。和聪明的人坐下来，我们几乎想出了这个模式，所以当我偶然发现这个模式时，我认为它非常适合我们，并且对于我们的持续部署和集成，因为合并到每个分支（main\dev、test、 prod) 正在进入正确的环境，分支稳定且永久，并且我的部门 (devops) 没有进行任何维护工作。我们只在这些分支上为我们想要自动化的更多应用程序添加更多构建和发布。
一家为我们提供咨询并且也在推广 Scrum 的外部顾问公司考虑了另一件事。我还无法理解动机，所以也许有人可以协助或反驳我或顾问在我们的案例中提供的内容（不是竞争，只是试图将解决方案附加到我公司的现实生活中）。他发送了以下网址：
使用 TFVC 的分支策略
其次是另一个参考：
简而言之-我们 v1.0在新分支上创建一个和我们的发布管道（ci cd）。这将始终改变，我们将在每个发布时更改管道（v2.0 , v50.0等等）。
我浏览了很多文章说特性分支策略不能很好地与持续集成一起工作——足够清楚，发布隔离建议每个发布都在一个新的分支上，有点类似于特性分支，我们应该希望一个发布能持续 2最多 -3 周将其合并到主分支。我只是看不出它是如何自动化的，它如何支持热修复自动化（热修复前一个分支将使我们更改所有构建以使用该分支），我将说明我的意思。
我正在使用带有发布管理的 TFS 2015 来执行持续集成构建和发布我们所有的代码都是 .Net ，在 windows 上。因此，我们有一个用于持续集成的分支，并且上面有触发器。我想提一下，在我的公司中，我们的服务有 30 多个（并且还在增加）构建和发布，我们有 200 多个应用程序，因此我们自动化了最紧急的应用程序，并且我们努力实现越来越多的自动化。
我在上面添加的链接中提供的解决方案（顾问共享它们）是每次有新版本时创建一个发布管道（每 2-3 周在 scrum 中工作）请注意，在 TFS Build 中，有对分支的特定引用应该构建（源和触发器），这意味着每个版本我们都必须将源和触发器中的所有分支名称以及 main sln \csproj 更改为发布分支的名称（例如 r12）。这会因项目而异，因为并非所有项目都具有相同的发布分支名称（例如，有些是 r5\r20），因此您不能自动覆盖每个不同应用程序构建的分支名称。
虽然它被写成好像这种类型的分支策略支持 tfvc 用于 devops 和持续交付，但这似乎是一项艰巨的冗余任务，为我们所有的自动化应用程序 EACH RELEASE 更改发布分支名称。这似乎是一个可怕的很多不必要的工作，没有明显的好处——当然对我来说。顾问确信他的解决方案更好更先进，Visual Studio 网站在同一篇文章中使用“连续”一词时展示了这个解决方案！另外，我们部门很小，手头有很多其他东西，谁能帮我看看我没看到的东西吗？
这是我们在每个版本中必须做的更改过程：
请注意，触发器在 tfs 2015 版本中不可克隆。
请注意，我想请求一个优雅的、非黑客的、可工作的证明（即使在理论上，这很好）解决方案，如果这意味着我们必须编写一个解决方法，则考虑根据我的经验增加了故障点和维护。
谢谢 ！