使用Gitflow和Gitversion进行一次构建，多次部署

Question

Gitflow适合我们的需求，而giversion似乎也适合gitflow。但是有一件事情我不太明白，让我解释一下我的疑惑。

1. 我们在develop分支上开发某些功能-所有软件包都标记为1.3.0-unstable.1、1.3.0-unstable.2等。
2. 每个软件包都经过管道-开发、测试、uat、prod。
3. 所以当开发完成并且一切准备就绪时，根据gitflow的规定，我们开始发布分支。
4. 发布分支上不需要进行任何更改，我们立即完成它-将发布分支合并到主分支和develop分支。
5. 构建服务器创建了一个更加稳定的软件包1.3.0，准备投入生产使用。

如何实现“一次构建，多次部署”？按照所有规则，我们需要将1.3.0-unstable.x提升到生产环境，因为这个软件包已经在dev和test中进行了测试，但是版本号看起来对于生产环境来说有点奇怪，不是吗？而从master分支获取的1.3.0从未在任何地方部署过。

类似于这个问题：在git flow模型中，我应该从master的合并提交构建到发布吗？ 答案并不令人满意：

1. 我们在将代码合并到主分支时使用-no-ff选项。
2. 它仍然是一个不同的软件包。

- Max

---

@hugo-ferreira，由于原始问题涉及到GitVersion的使用，因此二进制文件将不完全相同。 GitVersion将在AssemblyInfo文件中“盖章”断言版本号，这些版本号在发布分支和主分支之间将有所不同。 - Gary Ewan Park

@GaryEwanPark 我明白了...不知道gitversion是如何工作的，但这不再是使用gitflow的“分支策略”的问题，而是关于gitversion如何将版本号与二进制文件链接的问题。也许使用更通用的构建号或日期（参见http://semver.org的第10点）而不是“发布候选”（rc）表达/语义，它在生产中看起来会不那么奇怪？ - Hugo Ferreira

@HugoFerreira 这实际上是一个相当大的讨论，有很多不同的部分。对我来说，GitVersion和GitFlow是相辅相成的。当您在分支之间移动，创建热修复、发布和功能时，GitVersion会与您一起正确地确定当前状态的语义版本。然而，在我看来，无论是GitFlow还是GitVersion都无法很好地处理“一次构建，到处部署”的概念。也就是说，使用GitFlow，除非合并到主分支，否则无法在所有地方部署。 - Gary Ewan Park

@HugoFerreira 我认为你是对的 - 我需要配置gitversion，以便拥有一个通用版本，没有预发布后缀，但有元数据(1.3.0+release, 1.2.1+hotfix)。在这种情况下，根据semver规则，该版本是有效的，因为元数据会被忽略。 - Max

@8DH 花了我一些时间 :) - Max

Answer 1

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

我们的流水线发生了变化

从：dev-> test-> uat-> prod

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

所以就像我之前说的那样，我们正在使用github flow。每当我们在开发新功能时，首先从最新的主分支创建一个 featurename 分支。从该分支构建的每个版本都标记为1.3.0-featurename.1、1.3.0-featurename.2等。

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

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

- Max

---

那么，它被构建两次，一次用于开发和测试，另一次用于UAT和生产？ - karthikeayan