时间戳

首页 > 解决方案 > CI/CD 的 Git 分支和环境开发流程

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

问题描述

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

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

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

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

dev永远不会直接合并到staging中。当前的过程是使用cherry-pick从dev->获取代码，staging这样在环境中的QA步骤中就没有来自其他开发人员的任何东西dev被合并到staging不应该被合并的地方。

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

有没有更好的流程可以用于我们的环境建模？

标签： gitcontinuous-integrationcontinuous-deploymentagile

解决方案

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

环境：

  • 生产
  • 分期
  • 开发者

Staging旨在成为一个稳定的发布/环境，可以在任何时间点部署到 master。Dev是staging之前的 QA 和开发环境。

Git 分支：

  • 大师（生产）
  • 分期
  • 开发者
  • 功能/[名称] 错误修复/[名称] 等（遵循 git-flow 模式）

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

需要定期更新分支机构的内务管理 - 最重要的是，dev需要staging经常更新以保持 QA 环境的健康和最新。

推荐阅读