使用 GitFlow 进行构建推广到底是如何工作的？

Question

我很难理解促进构建（及其工件）的概念如何与 GitFlow 协同工作。我正在与 Git、Jenkins 和（作为新添加的）Artifactory 制定持续集成/交付工作流程。这是我迄今为止的工作：

• 来自develop分支的构建工件将自动推送到存储dev库（如果单元测试等通过）并因此提升为dev状态。这些工件无法进一步促销。
• 来自feature分支的工件根本不会被推送或提升。
• 来自release分支的工件也只能被提升到dev（或者我应该引入一个release回购？）
• 一旦release合并到 中master，新的提交就会被标记，Jenkins 就会运行完整的 CI/CD 管道。在单元测试和指标（在所有分支上运行的构建阶段）之后，工件被推送到一个masterrepo 并提升到master. 然后将工件用于部署到暂存环境，在那里可以进行最终测试（这些测试可以在完整的持续部署设置中自动化）。如果所有测试都成功，工件将被推送到一个prod仓库，部署到生产并提升到prod状态。如果在生产之前的任何阶段失败，则标签属于一个从未进入生产的版本。

我的理解正确吗？我主要对主/发布合并感到困惑。直觉上我会说，来自的二进制文件release将接受最多的测试。然而，GitFlow 规定只有在master被标记时提交（我不想标记技术上没有产生进入生产的二进制文件的提交）。如果在构建提交期间发现问题master怎么办？拥有未投入生产的标签是“错误的”吗？我是否必须恢复或撤消标签甚至合并提交？

很高兴听到其他人对此构建推广 + GitFlow 的看法。任何帮助深表感谢。

Answer 1

有这么多不同的分支模型，这么多人有自己的看法，我认为没有关于“GitFlow”是什么意思的明确参考。（请随时证明我是错的，我喜欢辩论这类事情）。

话虽如此，我（个人）发现这两个参考文献非常有帮助、完整且引人注目：

1. 原始 NVIE 博客文章
2. DataShift 细分

所以呢？

在我看来，你的前两点是正确的，后两点是错误的。

从构建提升的角度来看， allrelease和hotfixbranch 有资格（和预期）部署到您的test/staging环境以进行最终验证。来自 DataShift：

将发布分支中的代码部署到合适的测试环境中，进行测试，任何问题都直接在发布分支中修复。这个部署 -> 测试 -> 修复 -> 重新部署 -> 重新测试循环一直持续，直到您对版本足够好以向客户发布感到满意为止。

然后，一旦一切都经过验证，您就可以发布了：

发布完成后，发布分支也合并到 master 和 develop 中，以确保在发布分支中所做的任何更改不会被新的开发意外丢失。

或者，总结一下：

主分支仅跟踪已发布的代码。对 master 的唯一提交是从发布分支和修补程序分支合并。

这就是它变得棘手的地方，不同的项目有不同的意见：prod工件实际上来自哪里？

在我看来，你有两个选择：

1. 从再利用神器test/staging这是从内置release/hotfix支。
2. 从 中的提交重新构建工件master。

从纯代码的角度来看，这些是等效的 - 中的代码master与刚刚构建并部署到test/的代码完全匹配staging。但是，从构建过程的角度来看，事情可能会有所不同 - 不同的环境变量、不同的键等。

此外，您的团队如何看待test与staging.

那么该怎么办？

需要注意的是，这只是我的意见和staging意味着“生产镜像”的假设，我认为以下是一个明智的过程：

• 功能分支未部署到共享环境
• 该dev环境（如果存在的话）是内置/从部署develop分支
• 该test环境是建立/部署从release或hotfix分支
• 该staging环境是建立/部署从release或hotfix分支之后的正常检测/修复已完成。注意：您可以用RC标签指出这一点，但这是一个团队流程问题。
• 经过staging验证后，该代码合并从release/hotfix到master并标有发行版。
• 该prod部署环境与批准和测试神器staging。

最后的想法：

GitFlow 是一个很好的起点，但您最终将根据自己的需要对其进行自定义。不要害怕说“这对我们的团队有用”并按照自己的方式去做——只要确保写下来让每个人都明白你是如何做的。