CICD 的 Git 分支策略

Question

只是寻找关于以下分支策略的想法，牢记 CICD。

1. 主分支-

   1.1 开发分支 - 来自 master 的分支

             Team A branch - Fork from Development branch and merge to 
                             development branch after feature implementation 
                             for QA/Integration testing
   
             Team B branch - same as above
   
      1.1.1 Release branch - Goes in PROD
   

一旦团队 A 和团队 B 分支 merge 并完成 QA 验证，创建发布分支并对其进行最终回归。此发布分支将进入生产。

然后 merge Release到master分支。

意图-

1. 主分支稳定，生产运行代码可用。

2. Team branch可以部署在DEV环境，并且需要在服务器上配置CICD。

这种方法有什么问题吗？

Answer 1

要真正进行 CI(并且 CI 需要进行 CD)，您需要非常定期地 merge 到 master 并且没有长期存在的功能分支。我相信每天一次是“CI”。

您建议的另一种方法是为日常工作提供短期开发人员分支。然后拥有一个部署管道，通过一系列测试阶段移动每个代码更改。只有当变更通过每个阶段后，它们才会进入下一阶段并为生产做好准备。这允许您在 master 上工作但保持稳定并且只允许通过代码进入生产。

要处理独立的功能工作，您可以使用功能切换而不是分支。您可以打开功能并推送到 master 以测试它们并在一切正常时进行部署。如果没有，或者如果有业务需要删除某个功能，您可以关闭该功能并继续安全地使用 master。我已经看到这项工作在我开发的两种产品上非常有效。

我知道这很简单，但这只是为您提供替代方案的建议，希望对您有所帮助。您可以在一堆博客和 stackoverflow 答案中了解更多关于实现这些技术的信息- http://martinfowler.com/articles/feature-toggles- http://www.paulhammond.org/2010/06/trunk/alwaysshiptrunk.pdf- Feature Toggles vs Feature Branches