CI/CD 的 Git 分支和环境开发流程

问题描述

我有一个“开发过程”问题，希望得到一些经验和意见。

我与一家拥有典型 dev、staging 和 production 环境的公司合作。有十几个不同的 git 存储库和一个与 CI/CD 的每个环境相关的分支。

每天有大约 15 名开发人员在跨分支处理任务。 dev env 用于 QA，staging 是随时可用于生产的可部署 env。这都是正常的业务，没有环境问题。

这里是棘手的地方，将代码与 git 从一个环境合并到另一个环境的方向和过程：

dev 永远不会直接合并到 staging 中。当前的过程是使用cherry-pick 从dev -> staging 获取代码，以便在合并的dev env 中的QA 步骤中没有来自其他开发人员的任何内容进入不应该的staging。

IMO，这是一个非常混乱/有风险的过程，因为如果您 [开发人员] 从 dev 挑选您的提交到 staging，那么您可能会错过提交，您可以想象会由此产生！

---

我们可以在环境建模中采用更好的流程吗？

解决方法

我知道这是基于意见的，可能不是每个人/情况的正确答案。 （感谢@adam 提到 git-flow。）

环境：

• 生产
• 分期
• 开发

Staging 旨在成为一个稳定的版本/环境，可以在任何时间点部署到 master。 开发是分期之前的质量保证和开发环境。

Git 分支：

• 大师（制作）
• 分期
• 开发
• 功能/[名称] 错误修正/[名称] 等（遵循 git-flow 模式）

开发流程/流程： 为开发人员分配了一张票。开发人员从 staging 分支签出新功能/错误修复分支。开发人员在功能/错误修复分支和 MR/PR 的 dev 分支上完成自己的工作，以便可以在 dev 环境中对其进行 QA。票证通过 QA 后，开发人员会使用 feature/bugfix -> staging 打开 MR/PR。 feature/bugfix 合并到 staging 后可以丢弃。

内务需要定期更新分支机构的最新信息 - 最重要的是，dev 需要经常基于 staging 进行更新，以保持 QA 环境的健康和最新状态。