Maven和git流，候选版本的版本策略

我们正在尝试将git流模型应用于maven项目

我们使用

develope

和

feature/XXX

分支处理

-SNAPSHOT

版本化工件，这些工件部署在我们的

DEV

和

TST

环境中

当应用程序“就绪”时，我们有“发布候选”：代码被推送到

发布

分支上，我们编辑pom以更新版本（将

-SNAPSHOT

替换为

-RC1

），该版本被构建并存储在存储库管理器中，然后部署到

UAT

环境中

如果需要一些修复，我们将在同一

发行版

分支中创建其他

-RCx

版本，这些工件将归档在存储库管理器中，并部署在

UAT

env上。因此，我们可以精确地跟踪不同版本中的错误修复

一旦批准了

-RCx

版本，将

发行版

分支推送到

主版

，更新pom以删除

-RCx

，在部署到

产品

环境之前将其构建并存储在存储库管理器中

但是通过这种方式，部署在

PROD

和

UAT

中的二进制文件并不完全相同：由于

标记，两次战争中的POM是不同的。这并不是一个好的做法

如果我正确理解了git流模型，那么“最终”版本号（不带

-RCx

）应该在

发布

分支的创建时设置，并且在将该分支推送到

主

之前，同一版本是“活动的”，对吗？在这种情况下：

• 我们丢失了在

  UAT

  中实际部署的应用程序版本的信息（因为我们丢失了

  -RCx

  标识符，我们可能不知道部署的版本是否包含最后的错误修复，或者它是否是部署的旧版本…）
• 在repository manager中，我们无法知道工件是从

  发行版

  分支还是从

  主版

  构建的，因为将

  功能

  分支推入

  主版

  时版本号不再发生变化

什么更好？这两种方法的优缺点是什么？（不同环境上的不同二进制文件-vs-没有确定的候选版本。）

---

在git流模型中，您（或您会）如何使用Maven项目管理候选版本？

我建议您在版本控制策略中添加修订号。当您启动发布分支时，修订号被设置为0，然后随着每次修复而递增。测试完成后，将验证测试的确切版本部署到生产环境中。这种方法为每个版本提供了可跟踪性，在不同的环境中保持版本的一致性，并且避免了仅仅围绕版本号进行形式化的新构建的需要。在测试环境中验证的完全相同的二进制文件可以部署到生产环境中

我已经在几个生产应用程序中使用了此策略，并且没有出现任何问题