6

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

  1. 我们确实在开发分支上开发了一些功能——所有的包都被标记为 1.3.0-unstable.1、1.3.0-unstable.2 等等。
  2. 每个包都通过管道 - dev、test、uat、prod。
  3. 所以当开发准备好并且一切都很好时，根据 gitflow 我们启动发布分支。
  4. 发布时不需要做任何更改，我们马上就完成了——发布分支合并到主分支和开发分支中。
  5. 构建服务器再创建一个包 1.3.0，这是一种产品准备就绪。

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

问题与此类似：在 git flow 模型中，我应该从 master 中的合并提交构建到发布吗？

答案并不令人满意：

  1. 我们在合并到 master 时执行 -no-ff
  2. 它仍然是一个不同的包
4

1 回答 1

1

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

我们的管道发生了变化

来自：开发 -> 测试 -> uat -> 产品

to: dev -> test 然后 uat -> prod

所以就像我之前说的，我们使用的是 github 流。每当我们处理新功能时，首先 - 我们从最新的 master创建一个分支功能名称。此分支的每个构建版本都像这样 1.3.0-featurename.1、1.3.0-featurename.2 等等。

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

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

于 2016-11-15T20:04:19.953 回答