CICD的Git分支策略

Question

只是在考虑以下分支策略时要牢记CICD。

1. 主分支-

   1.1开发部门-大师级的分叉

     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分支合并并完成质量检查后，请创建发布分支并对其进行最终回归。 此发行分支将进入生产。

然后将Release合并到master分支。

目的-

1. 主分支是稳定的，并且其中包含生产运行代码。

2. Team分支可以部署在DEV环境上，并且在服务器上具有必需的CICD配置。

这种方法有什么问题吗？

Answer 1

这不是真正的CI（用CI，我指的是开发策略，而不是工具），因为您有团队分支，这意味着团队的工作直到合并到master中才被整合-总是有其他团队看不到并且看不到他们的工作的团队。查看其他团队的工作（因此可以进行调整基准/合并地狱 ）。

对于真正的CI战略的所有团队将在工作master （如果真的拉任务的分支，他们会被合并到主非常快，不超过几天的寿命更多） -每个人都几乎是在同一页上。

CI工具（可能在暂存环境中为CD工具）将密切关注master健康状况。

只要master是current release就绪的，或者当下next release更改开始与current release发生冲突（发行分歧）时， current_release分支就会被拉出，并且永远不会合并回master（由于发行分歧，这种合并将是一个大问题） 。 current_release任何错误修复（如果也适用于master ）都将被精心挑选和两次提交（仅因为一个分支上的修复是确定的，并不意味着它在另一分支上是确定的）。

实际上， current_release分支是您的生产分支。 它需要根据current release功能量身定制的CI / CD设置。 生产版本只是该分支上的标签。

master分支将继续朝着next release发展。

冲洗并重复。

您还可以为多层发行版（major / minor / etc）提供current_release其他子分支，这些子分支也永远不会合并回其父分支。 每个此类子分支与其父级之间的关系与current_release和master之间的关系完全相同。

Answer 2

要真正地执行CI（并且需要CD才能执行CI），您将非常有规律地合并以掌握母带，并且没有很长的功能分支。 我相信，每天将其设置为“ CI”。

您建议的一种替代方法是让短暂的开发人员分支从事日常工作。 然后要有一个部署管道，通过一系列测试阶段来移动每个代码更改。 只有在每个阶段都通过更改后，它们才能进入下一个阶段并准备投入生产。 这使您可以在主服务器上工作，但保持稳定，并且只允许传递代码进入生产环境。

要处理独立的要素工作，可以使用要素切换而不是分支。 如果一切正常，您可以打开功能并按下以测试它们并进行部署。 如果不是这样，或者如果业务需要删除某个功能，则可以关闭该功能并继续安全使用master。 我已经在使用的两个产品上看到了很好的效果。

我知道这非常简化，但这只是为您提出替代建议，希望对您有所帮助。 您可以了解更多有关在大量博客上实现这些技术以及stackoverflow答案的信息-http: //martinfowler.com/articles/feature-toggles-http : //www.paulhammond.org/2010/06/trunk/alwaysshiptrunk.pdf - 功能切换与功能分支