DevOps中的分支策略

Question

我正在用TFS建立DevOps过程，并且想知道分支策略。如果我有下面的示例分支(来自指导: Scrum团队的分支策略的图像)。

​

​

我已经建立了DevOps流程(连续集成和连续交付)，并从主分支(与Jenkins)进行了连续集成。

• 我该如何处理修补程序？如果开发人员经常合并到主分支来验证构建，那么如何获得最后发布的应用热修复的代码？如果我要使用发布分支，我最终将不得不将热修复集成到主分支，以启动CI过程。但是，主分支可以包含版本以外的更改。

请就这个问题提出建议。

Answer 1

通常，热修复应该从主分支的相关版本中提取出来。然后需要为热修复创建一个专用分支，并将其与最后一个稳定的分支合并。如果它通过了整个QA、单元测试、系统测试等，那么将其合并回主分支作为下一个发布版本。

在使用git时，您可以在下面的示例中查看引用：git最佳实践。源代码管理不是问题，而是主要思想。仔细阅读这篇文章，我相信你能找到你要找的东西。

有些组织还在处理补丁程序.我不太喜欢这个解决方案，但是如果这是你的情况，请告诉我，因为补丁中有一些不同的解决方案。

Answer 2

修补程序是发布软件的修补程序。如果您有一个发布分支，那么创建一个修复分支是合适的。在将该修补程序提升为Prod之后，您可以将向上的链反向集成到Main。如果需要，热修复->发布-> Main，甚至将其集成到下一个sprint。

Answer 3

显然，您所选择的答案取决于您的特定需求；但是，通常您应该从main中削减一个发行版，并从发布分支中删除一个热修复。就我个人而言，我想说的是，该代码不应该返回到发布分支中，而应该在开发分支中进行双修复。

这样做的主要原因是，一旦您发布了代码，该代码分支就应该像发布时一样被锁定。如果你遵循这一点，那么你总是可以回到以前的状态。如前所述，当需求或优先级发生变化时，或者当客户在活动代码中报告错误时，您可能正在对修补程序进行中途更改。如果您维护一个单独的分支，则始终可以访问该代码。