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 分支合并并完成 QA 验证，创建发布分支并对其进行最终回归。此发布分支将进入生产环境。

然后将 Release 合并到 master 分支。

意图-

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

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

这种方法有什么问题吗？

Answer 1

要真正做 CI（而且 CI 是做 CD 所必需的），您将非常定期地合并到 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

Answer 2

这不是真正的 CI（CI 是指开发策略，而不是工具），因为您有团队分支，这意味着团队的工作在合并到 master 之前不会集成 - 总是有团队的工作对其他团队不可见，并且没有看到其他团队的工作（因此对变基/合并地狱开放）。

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

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

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

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

master 分支继续向next release 发展。

冲洗并重复。

您还可以将current_release 的更多子分支用于多级版本（主要/次要/等），它们也从不合并回其父分支。每个这样的子分支和它的父分支之间的关系就像current_release和master之间的关系一样。