Tfs 分支策略-通过连续部署/集成释放隔离？

在过去的2.5年中，我一直在使用TFS和rm创建构建和发布版本（同样使用rm 13）

最近，我尝试在我们公司的分支战略中嵌入“按质量分支”模式。 在我们的开发过程中，我们需要热修复合并、sprint合并、bug修复合并。下面是一个小例子：

我们可以同意，在生产之前将热修复程序上传到测试环境会将qa当前正在测试的所有新功能与我们想要的小型紧急热修复程序混合在一起，因此代码是脏的。与聪明人坐在一起，我们几乎想出了这种模式，因此当我偶然发现这种模式时，我认为它将非常适合我们，对于我们的持续部署和集成，因为每个分支（main\dev、test、prod）的合并将进入正确的环境，并且分支是稳定和永久的，并且不需要我的部门（devops）的维护工作。我们只在这些分支上添加更多的构建和发布，以实现更多我们想要自动化的应用程序

一家为我们提供咨询的外部顾问公司，同时也在推广Scrum，还有另一个想法。我还不能理解其动机，所以也许有人可以在我们的案例中帮助或反驳我或顾问提供的服务（不是竞争，只是试图将解决方案与我公司的现实生活联系起来）。 他发送了以下网址：

然后是另一个参考：

简言之，我们可以在新分支上创建一个

v1.0

和我们的发布管道（ci cd）。这将始终改变，并且我们会在每个版本上更改管道（

v2.0、v50.0

等等）

我读了很多文章，说功能分支策略在持续集成中不能很好地工作——足够清楚，发布隔离 建议每个版本都在一个新的分支上，有点类似于功能分支，我们应该希望一个版本最多持续2-3周，以便将其合并到主分支。 我只是看不到它是如何实现自动化的，它是如何支持热修复自动化的（热修复以前的分支） 将使我们更改所有构建以与该分支一起工作），我将展示我的意思

我使用TFS 2015和发布管理来执行持续集成构建和发布，我们所有的代码都是.Net，在windows上。因此，我们有一个用于连续积分的分支，它上面有触发器。我想说的是，在我的公司里，我们有30多个（而且还在增加）版本和发布我们的服务，我们有200多个应用程序，所以我们自动化了最紧急的应用程序，我们努力自动化越来越多的应用程序

我在上面添加的链接（顾问分享了它们）中提供的解决方案是创建一个发布管道 每次有新版本（每2-3周在scrum中工作一次） 请注意，在TFS构建中，对应该构建的分支（源和触发器）有特定的引用，这意味着每个版本我们都必须将源和触发器以及主sln\csproj中的所有分支名称更改为发布分支的名称（例如r12）。 这在不同的项目中会有所不同，因为并非所有项目都具有相同的发布分支名称（例如，有些项目将是r5\r20），因此您不能仅自动覆盖每个不同应用程序的生成的分支名称

尽管这种类型的分支策略在编写时似乎支持用于devops和连续交付的tfvc，但在每个版本中为我们所有的自动化应用程序更改发布分支名称似乎是一项非常繁重的任务。。 这似乎是大量不必要的工作，没有明显的好处-当然对我来说。 这位顾问确信他的解决方案更好、更先进，VisualStudio网站在同一篇文章中使用了“Continuous”一词，同时展示了此解决方案！ 另外，我们的部门很小，手头还有很多其他的东西，有人能帮我看一下我看不到的东西吗

这是我们在每个版本中必须进行的更改过程：

请注意，触发器在tfs 2015版本中不可克隆。

请注意，我想请求一个优雅的、非黑客的、证明有效（即使在理论上，这也很好）的解决方案来解决这个问题，如果这意味着我们必须编写一个解决方案，根据我的经验，它被认为是故障点和维护的补充

---

谢谢

你的问题太笼统了，可能有点主观。没有普遍认可的“最佳”分支策略适用于任何项目 大多数资源似乎都同意，选择生产性战略取决于特定的项目细节 旁注。

根据这一点，似乎需要对项目分支策略的任何更改进行测试、测量，并与其他测试选项进行比较

您在第一个解决方案中没有明确提到如何处理发布。生产发布是来自主干/主干还是分支。根据大多数其他人在谷歌上的经验：

从主干中执行prod释放基本上是禁止使用的 不稳定的主干策略。从分支执行prod发布的团队 更多分支选项可供选择

---

此外，关于热修复和自动化在您的顾问分享。通常，我们在“功能完成”时创建发布分支，并计划在此代码行上修复最后一分钟的问题。正如上面的教程和屏幕截图所示，当您需要为已经发布的代码创建bug修复程序时，这个过程看起来就像是从一个版本分支出来的。在这种情况下，可能不需要修复以前的每个分支

在第一个解决方案中，我们在每一行上有3个发布分支，Dev（Main）有自己的发布管道，因此他们可以有一个游戏场地，测试也可以自动部署在QA envi中