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

Question

我很难理解提升构建（及其工件）的概念究竟是如何与 GitFlow 一起工作的。我正在使用 Git、Jenkins 和（作为新增功能的）Artifactory 制定持续集成/交付工作流程。这是我到目前为止所制定的：

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

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

很高兴听到其他人对这个构建推广 + GitFlow 的方法。非常感谢任何帮助。

Answer 1

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

话虽如此，我（个人）发现这两个参考资料非常有用、完整且令人信服：

1. Original NVIE blog post
2. DataShift breakdown

---

那么，什么？

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

从构建提升的角度来看，所有 release 和 hotfix 分支都符合（并且预期）部署到您的 test/staging 环境以进行最终验证。来自 DataShift：

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

然后，一旦一切都得到验证，你就可以发布了：

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

或者，总结一下：

主分支只跟踪发布的代码。对 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 是一个很好的起点，但您最终还是要根据自己的需要对其进行自定义。不要害怕说“这对我们的团队有用”并按照自己的方式去做 - 只需确保将其写下来，以便每个人都了解您的做法。