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

Question

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

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

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

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

Answer 1

有这么多不同的分支模型，这么多人有自己的看法，我认为没有关于“GitFlow”含义的明确引用。 (请随意证明我错了，我喜欢辩论这种事情)。

话虽如此，我(个人)发现这两个引用资料非常有帮助、完整且引人注目:

1. Original NVIE blog post
2. DataShift breakdown

---

那么，什么？

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

从构建提升的角度来看，所有 release 和 hotfix 分支都有资格(并且预期)部署到您的 test/staging 最终验证的环境。来自 DataShift:

The code in the release branch is deployed onto a suitable test environment, tested, and any problems are fixed directly in the release branch. This deploy -> test -> fix -> redeploy -> retest cycle continues until you’re happy that the release is good enough to release to customers.

然后，一旦所有内容都经过验证，您就可以发布了:

When the release is finished, the release branch is merged into master and into develop too, to make sure that any changes made in the release branch aren’t accidentally lost by new development.

或者，总结一下:

The master branch tracks released code only. The only commits to master are merges from release branches and hotfix branches.

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

在我看来，您有两个选择:

1. 重新使用从 release/hotfix 分支构建的 test/staging 的 Artifactory 。
2. 根据 master 中的提交重新构建 Artifactory 。

从仅代码的角度来看，它们是等效的 - master 中的代码与刚刚构建并部署到 test 中的代码完全匹配/暂存。但是，从构建过程的角度来看，情况可能有所不同 - 不同的环境变量、不同的 key 等。

此外，您的团队如何看待 test 与 staging 的关系可能会变得复杂。

---

那么，该怎么办？

请注意，这只是我的意见，并且假设 staging 表示“生产镜像”，我认为以下是一个明智的过程:

• 功能分支未部署到共享环境
• dev 环境(如果存在)是从 develop 分支构建/部署的
• test 环境是从 release 或 hotfix 分支构建/部署的
• staging 环境是在正常测试/修复完成后从 release 或 hotfix 分支构建/部署的。注意:您可以使用 RC 标记来表明这一点，但这是一个团队流程问题。
• staging验证完成后，代码从release/hotfix merge 到master，并标记为发布版本。
• prod 环境使用来自staging 的已批准和测试的 Artifactory 进行部署。

---

最后的想法:

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