我很难理解提升构建（及其工件）的概念是如何与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的方法。任何帮助都非常感谢。
1条答案
按热度按时间23c0lvtd1#
有这么多不同的分支模型，这么多人有自己的想法，我不认为有一个明确的参考“GitFlow”的意思。（请随时证明我错了，我喜欢辩论这类事情）。
话虽如此，我（个人）发现这两个参考资料非常有帮助，完整，令人信服：
所以呢
在我看来，你的前两点是对的，后两点是错的。
从构建升级的Angular 来看，所有的
release和hotfix分支都有资格（并且预期）部署到您的test/staging环境中进行最终验证。来自DataShift：发布分支中的代码被部署到一个合适的测试环境中，并进行测试，任何问题都直接在发布分支中修复。这个部署->测试->修复->重新部署->重新测试的循环会一直持续下去，直到你满意地认为这个发布足够好，可以发布给客户。
然后，一旦一切都得到验证，你准备发布：
当发布完成时，发布分支被合并到master和develop中，以确保在发布分支中所做的任何更改不会被新的开发意外丢失。
或者，总结一下：
master分支只跟踪发布的代码。master的唯一提交是来自release分支和hotfix分支的合并。
这里是它变得棘手的地方，不同的项目有不同的观点：
prod工件实际上来自哪里？在我看来你有两个选择
1.重用从
release/hotfix分支构建的test/staging中的工件。1.从
master中的提交重新构建工件。从 * 仅代码 * 的Angular 来看，它们是等效的-
master中的代码与刚刚构建并部署到test/staging的代码完全匹配。然而，从 * 构建过程 * 的Angular 来看，事情可能有所不同-不同的环境变量，不同的键等。此外，您的团队如何看待
test与staging，事情可能会变得复杂。那该怎么办
注意，这只是我的观点，并假设
staging意味着“生产镜像”，我认为以下是一个合理的过程：dev环境（如果存在）从develop分支构建/部署test环境是从release或hotfix分支构建/部署的staging环境是在正常测试/修复完成后从release或hotfix分支构建/部署的。注意：您可以使用RC标记来指示这一点，但这是一个团队过程问题。staging验证完成后，代码将从release/hotfix合并到master，并标记为发布版本。prod环境部署了来自staging的经过批准和测试的工件。最后的想法：
GitFlow是一个很好的起点，但你最终还是要根据自己的需求来定制它。不要害怕说“这是我们团队的工作”，并按照自己的方式去做-只要确保它被写下来，让每个人都明白你是如何做的。