从主分支还是热修复分支部署到生产环境？

Question

3

我们公司在使用SVN几年之后，现在采用Git。Git Flow的主干/热修复/开发/发布分支非常适合我们的需求。到目前为止，一切都很顺利，除了一个难题。

我们的项目是一个Java应用程序，在项目构建时会生成一个WAR文件。

具体情况如下：

- 我们以master作为生产代码的主干 - 从master中新建热修复分支 - 开发人员提交热修复代码 - QA对热修复进行测试 - 经过QA批准的二进制文件

所以问题来了：

- 应该从热修复分支将二进制文件部署到生产环境中吗？ - 还是应该将代码合并到主干，从那里构建、测试，然后再部署到生产环境中？

我知道master应该是用于持有即将部署到生产环境的代码的。因此，我对从热修复分支部署有疑问。

但是，从master部署可能意味着在同一代码库上进行两个QA周期，因为（在热修复和master上）进行的2个构建可能会根据maven依赖项/构建环境等产生不同的二进制文件。进行两个相同的代码库的QA周期是浪费资源的行为。

我在网上搜索了一些相关的内容，但发现很少有人谈及此问题。有些人说他们从master部署，而其他人则从热修复分支部署。主要是因为从master进行构建的通常都是解释性语言项目（如PHP、Perl等），这些语言没有二进制文件需求。

你们是否遇到过这个问题？采取了哪种方法呢？

提前感谢！

- Murilo Yoshida

2个回答

-1

这是一篇关于Git分支的优秀文章 - 希望能对您有所帮助。

- aked

我熟悉这个@dekdev，谢谢！但是你看例如标签0.2。潜在的二进制文件是在合并到主分支之前的红色热修复提交上推送到生产环境还是在主分支上合并后推送？如果在热修复中，那么为什么我们不在热修复中打标签0.2而是在主分支上呢？ - Murilo Yoshida

1

实际上，我在阅读的链接中看到：“因此，每次将更改合并回主分支时，从定义上来说，这是一个新的生产发布版本。我们在这方面往往非常严格，因此理论上，我们可以使用Git钩子脚本自动构建和部署我们的软件到我们的生产服务器上，每次在主分支提交时。” - Murilo Yoshida

1

该图没有显示有关部署的内容，只是展示了分支合并策略，而这并不是 OP 所询问的。 - Qwerky

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

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

- Magnus Bäck · Accepted Answer

创建短期发行分支进行小补丁的分支，其目的在于您可以选择准确应用到已知状态的内容。您可能有一个1.0.0版本，但需要修复一些错误以制作1.0.1版本。在这种情况下，从1.0.0分支并应用您的错误修复，然后从那里发布是有意义的。

从发布分支合并到主分支并从那里发布也可以，但这就引出了为什么要首先创建分支以及是否这实际上是热修复的问题。从质量方面来看，最好在目标分支上开发而不是孤立地工作并在最后进行最终合并——因为正如您所说，您需要两个 QA 循环。

需要问的问题似乎是您是否想要严格控制要包括在新版本中的提交，或者您是否满足于任何包含该提交集的版本。

对我来说，不清楚部署类型（未编译脚本语言与编译语言）如何与讨论相关。