一次构建，使用gitflow和gitversion部署许多

Question

gitflow符合我们的需求，而giversion似乎也符合gitflow。但是有一件事我还不完全了解。让我解释一下困扰我的事情。

1. 我们在开发分支上做了一些功能上的工作-所有软件包都标记为1.3.0-unstable.1、1.3.0-unstable.2，依此类推。
2. 每个软件包都将通过管道-开发，测试，测试，生产。
3. 因此，当开发人员准备就绪并且一切都很好时，根据gitflow我们启动了release分支。
4. 发行时不需要做任何更改，我们会立即完成它-发行分支已合并到主版本和开发中。
5. 构建服务器会再创建一个软件包1.3.0，该软件包已准备就绪。

如何实现一次构建，在这里部署多个？根据所有规则，我们需要将1.3.0-unstable.x升级到prod env，导致此软件包确实在dev和test中进行了测试，但是该版本对于prod看起来有点奇怪，不是吗？当来自master分支的1.3.0从未部署到任何地方时。

问题是这样的：在git flow模型中，我应该从master的merge提交构建到发布吗？

答案并不十分令人满意：

1. 我们在与主人合并时不做-ff
2. 还是一个不同的包裹

Answer 1

让我自己来回答这个问题。我们意识到使用 gitflow 支持多个版本/多个环境是一个巨大的负担。因此，我们正在寻找更简单的东西，那就是github flow。当然，它并没有完全解决我们最初的问题（构建一次 - 部署多次），但这就是我们部分解决它的方式。

我们的管道发生了变化

来自：dev -> test -> uat -> prod

到： dev -> test 然后 uat -> prod

正如我之前所说，我们正在使用 github 流程。每当我们开发新功能时，首先 - 我们从最新的主版本创建一个分支功能名称。该分支的每个构建版本都类似于 1.3.0-featurename.1、1.3.0-featurename.2 等。

一旦开发人员完成其实现并完成所有开发检查，这些确切的二进制文件就会进入测试环境进行质量检查。在 QA 人员签署此版本后，我们很高兴将其推入我们的第二个管道 uat -> prod。我们合并featurename分支的拉取请求和之后获得的构建版本，比方说：1.3.1 进入 uat 环境。一旦在那里签署，我们就会将完全相同的二进制文件推送到生产环境。

如果同时开发多个功能分支，我们推送到测试环境的下一个版本应该基于最新的主版本并再次通过管道重新构建。