分支策略-使用持续部署/集成发布隔离？

Question

在过去的2.5年中，我一直在使用TFS和RM创建构建和发行版(也使用rm 13)。

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

​

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

一家为我们提供咨询的外部顾问公司，以及正在推广Scrum的公司，还想到了另一件事。我还不能理解动机，所以也许有人可以帮助或反驳我或顾问在我们的情况下提供的(不是一个竞争，只是试图把解决方案与我的公司的现实生活)。他发送了以下urls：基于TFVC的分支策略

​

其次是另一个参考：

适用于DevOps的有效TFVC分支策略

​

简而言之，我们可以创建一个v1.0，新branch.this上的发布管道(ci cd)总是会改变的，并且我们会在每个版本(v2.0 , v50.0等等)上更改管道。

我读过很多文章，说功能分支策略与持续集成不太好--足够清晰，发布隔离建议每个发布都在一个新分支上，有点类似于特性分支，我们应该希望一个版本最多能持续2-3个星期才能将它合并到主分支。我只是不明白它是如何自动化的，它是如何支持热修复自动化的(前一个分支的热修复将使我们更改所有构建来使用该分支)，我将展示我的意思。

我正在使用TFS 2015与发布管理一起执行持续集成构建，并在windows上发布我们所有的代码都是.Net。因此，我们有一个分支，用于连续积分，并在其上有触发器。我想提到的是，在我的公司，我们有30多个(而且还在增加)构建和发布我们的服务，我们有超过200个应用程序，所以我们自动化了最迫切的应用，我们努力使越来越多的自动化。

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

虽然这种分支策略的编写方式似乎支持tfvc用于devops &连续交付，但它似乎是一项艰巨的冗余任务，要为每个版本的所有自动化应用程序更改发布分支名称，似乎是一项艰巨的冗余任务。这似乎是一个非常多的不必要的工作，因为没有明显的优势-当然对我。顾问对他的解决方案更好、更先进很有信心，Visual网站在同一篇文章中使用“连续”一词展示了这个解决方案！另外，我们的部门很小，手上有很多其他东西，有人能帮我看一下我看不到的东西吗？

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

​

注意，触发器在tfs 2015构建中是不可复制的。

​

请注意，我想要求一个优雅的，而不是一个黑客，证明-工作(即使在理论上，这是好的)解决这个问题，如果这意味着我们必须编码一个解决办法，它被认为是一个附加的故障点，和维护根据我的经验。

谢谢！

Answer 1

你的问题太板上钉钉了，也许有点主观。没有一致同意的“最佳”分支策略适用于任何项目--大多数资源似乎都同意，选择生产性策略取决于特定项目的具体情况。

根据这一点，项目分支策略的任何更改都需要进行测试、度量和与其他选项测试的进行比较。

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

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

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