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

Question

我使用TFS和RM创建了过去2。5年（也是使用rm 13）的构建版本。

最近，我试图嵌入“按质量分支”。我们公司的分支战略模式。 我们需要在我们的开发过程中进行热修复合并，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等等。）

我经历了很多文章，说功能分支策略在持续集成方面效果不佳 - 足够清楚，发布隔离 建议将每个版本放在一个新的分支上，类似于功能分支，我们应该希望一个版本最多可以持续2-3周将其合并到主分支。 我只是看不出它是如何自动化的，它如何支持热修复自动化（热修复前一个分支 将使我们改变所有构建以与该分支一起工作）并且我将展示我的意思。

我正在使用TFS 2015和Release Management来执行持续集成构建，并在Windows上发布我们的所有代码.Net。因此，我们有一个分支，用于连续集成，并在其上有触发器。我想提一下，在我的公司，我们有超过30个（并且正在增加）我们的服务构建和发布，我们有200多个应用程序，所以我们自动化最紧急的应用程序，我们努力实现越来越多的自动化。

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

虽然它被写成好像这种类型的分支策略支持devop的tfvc＆amp;持续交付，似乎是一项艰巨的冗余任务，为所有自动化应用程序EACH RELEASE运行更改发布分支名称。 这似乎是一项非常多的不必要的工作，因为当然没有明显的优势 - 对我来说。 顾问确信他的解决方案更好，更先进，Visual Studio网站在使用“连续”字样时显示了这个解决方案。在同一篇文章中！ 另外，我们的部门很小，手上有很多其他的东西，任何人都可以帮我看看我没看到的东西吗？

这是我们在每个版本中必须要做的变化过程：

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

请注意我想请求一个优雅的，不是黑客的，证明工作（即使在理论上，这很好）解决这个问题，如果这意味着我们必须代码一种解决方法，根据我的经验，它被认为是故障点和维护的补充。

谢谢！

Answer 1

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

根据这一点，看起来项目分支策略的任何变化都需要测试，测量并与其他测试选项进行比较。

您没有提到如此清楚如何处理第一个解决方案中的版本。生产版本是否来自主干/主要或分支。根据大多数其他人在谷歌上的经验：

  

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

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