将git-flow模型应用于预生产环境

Question

将git-flow模型应用于预生产环境

21

我正在考虑将git-flow模型扩展到我目前的工作场所，因为有一个特定的情景需要。但是我的情况非常普遍，以至于我很惊讶没有人在git-flow模型中做过这个，这让我觉得我可能错过了一个显而易见的问题。我的问题是：我的提议扩展有缺陷吗？

情景是这样的：我有许多开发团队从一个共同的代码库进行开发，并通过几个（永久的）环境推出发布：首先是系统集成环境（SIT），然后是用户验收测试环境（UAT），然后是预生产环境，最后是生产环境。这是严格按顺序进行的，尽管任何发布候选版本都可能在任何环境中失败，因此无法进一步推进。因此，每个后续环境只是前一个环境的移动速度较慢的版本。

我们正在引入git进行源代码控制，我们需要一个工作流程，而git-flow看起来是一个不错的开始。

We asked ourselves how to capture (i.e. how to know) what's in each environment at any time. The git-flow model seems to have essentially two core states: main and develop. They have an "infinite lifespan". Other branches are just "supporting branches" with a "limited life time". They exist only to allow development and to go from development to production (via a temporary release state). The git-flow model is based around going from development to release.

However, this doesn't map logically onto our scenario, with its multi-stage release sequence. I'm fine with the develop branch, of course. And the main branch clearly does map to our production environment. The original git-flow description says this about main:

每次更改合并回主分支时，根据定义，这是一个新的生产发布。我们倾向于非常严格地执行此操作，以便在理论上，我们可以使用Git钩子脚本在每次对主分支进行提交时自动构建和部署软件到我们的生产服务器。

由于“main”是生产的连续记录，似乎一致的做法是应该为SIT、UAT和预生产设置相应的分支以扩展git-flow模型。毕竟，它们是永久环境，具有严格的发布流程。它们只是比生产环境变化得快一点而已。

这些额外的永久分支位于“develop”和“main”之间，就像它们相应的环境一样。

这意味着现在很容易追踪每个环境的版本发布和状态。对于每个环境的合并也更加容易了：SIT分支需要从develop进行合并，UAT分支需要从SIT分支进行合并，pre-prod分支需要从UAT分支进行合并，最后main分支（用于生产）需要从pre-prod分支进行合并。每个后续分支只是前一个分支的速度较慢的版本。

我有遗漏什么吗？

- Nik Silver

你可以通过仅对其他分支执行快进合并来实现相同的效果。现在它们只是指向develop过去状态的指针，实际上你并没有真正改变git-flow模型 :)。 - Chronial

我想知道您是否能够实现这个分支策略。我有完全相同的要求。我有以下环境：DEV - INT - QA - PROD。我正在考虑做与您完全相同的事情。我想为每个环境创建一个具有无限生命周期的分支。您能否分享一下您实施这个分支策略的经验？在您的经验中，您认为这值得吗？ - Jupaol

实际上，我们最终没有实现这个。我们选择了完全不使用分支（除了主分支和偶尔的分支来修复之前版本中的错误）。每次推送的更改都会被重新基于主分支的末尾。由于团队对Git还不熟悉，这样做更简单。它迫使个人开发人员频繁地推送小而连贯的更改。此外，通过拥有单一的直线，意味着历史记录对于与开发团队分离的支持团队来说更容易跟踪。如果可以选择，我会再次以这种方式进行。 - Nik Silver

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- mproffitt · Accepted Answer

我没有看到任何理由需要根据您的模型进行调整。您说您按顺序工作 SIT -> UAT -> Pre-Prod，完美无缺。一旦开发稳定（即要发布的所有功能都已完成），则执行release start并将其移动到您的 SIT 平台进行 QA。一旦开始发布，开发就可以继续在develop分支上进行。直到发布完成，master保持静态。

一旦QA满意，则将发布分支移至UAT。通过UAT测试并将代码推送到生产环境，并使用 release finish 合并回主分支/开发分支。 master 应始终反映当前正在运行的平台的状态，而develop 则反映活跃开发的代码的状态。release 分支包含对 develop 的静态剪切，其中应用 bug 修复（不会将任何新特性推入此分支，否则您将无法使用 git-flow）。

基于您的描述，我倾向于认为您误解了 git-flow 模型，因为从我所看到的情况来看，它完全符合您描述的场景，您只需要在 SIT -> UAT -> Pre-Prod 阶段关注 release 分支，甚至可以忽略 master / develop 的存在。

回应评论

自我发布这篇回答以来，已经有许多评论提出了关于模型在不同场景下如何工作的问题。

客户要求改进现有功能

回答：

严禁（我再三强调）在发布分支中添加新功能/增强功能。这是范围蔓延。新功能就是新的工作。它们需要单独进行成本估算并且必须要单独处理。无论你的客户是公司内部还是第三方，他们都理解成本。向他们指出，如果他们打断了发布流程，将会无限期地延迟它或者现有的测试将受到影响。把发布分支视为master一样神圣，只允许对其进行漏洞修复。

分支寿命

如果你的发布分支持续数月，则你的发布循环时间太长。我曾在发布周期平均每3周的场所以及发布频率为每几天一次的其他场所工作过。3周应该足够进行QA和UAT发布分支。如果你正在考虑更长的周期，则我认为公司不具备敏捷性，并且：

git-flow是错误的分支策略（值得怀疑，在精心管理时，它可以在几乎任何情况下运行）
你需要认真质疑公司为什么有这么长的发布周期
（最有可能的情况）- 你不理解Git-Flow
1. CI

我已经非常成功地将 Git-Flow 与 CI 一起使用。虽然这主要是在 Jenkins 和 Bamboo 上，但它也适用于 Travis CI。

基于提交的 Git Hook 正是任何分支构建的工作原理。我使用过的最好示例会在提交（或一系列提交）推送到远程时自动构建，然后挂钩启动并调用 CI 平台。CI 平台然后找到相关的作业（可以使用内置模板或使用第三方模块）以触发构建。

我的个人设置是在以下情况下触发本地 Jenkins 实例：

我创建一个分支（在当前分支中创建一个新的 jenkins 作业）

我提交（触发本地分支的构建）

本地构建通过，可以自动推送到远程

我推送新的分支（在远程CI中创建目标构建）

我推送提交（触发远程CI目标实例）

我删除本地分支（删除本地作业）

我删除远程分支（删除远程作业）

我提出合并请求（将feature/A软合并到develop并进行测试-测试失败，自动拒绝合并）

这需要一些配置，但任何现代CI平台都可以实现。

像其他任何东西一样，使用Git-Flow的规则只是指导方针。没有硬性规定。如果您想要一个长期存在的发布分支，那是您的选择但是，除非您注意它们，否则您将得到一个分叉的代码库，这将很难合并回来。

Git-Flow和其他来源于*nix工具的东西一样，只是一种工作方式，随之而来的是许多选择。这个工具和工作流程只是对GIT的包装器。您如何选择实施它完全取决于您自己。