Maven 和 git-flow，候选版本的版本策略

Posted 2023-03-30

【中文标题】Maven 和 git-flow，候选版本的版本策略

【英文标题】：Maven and git-flow, version strategy for release candidates

【发布时间】：2017-06-04 01:05:31

【问题描述】：

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

我们使用develop 和feature/XXX 分支来处理-SNAPSHOT 版本化的工件，这些工件部署在我们的DEV 和TST 环境中。

当应用程序“准备好”时，我们有“发布候选”：代码被推送到release 分支上，我们编辑 pom 以更新版本（将-SNAPSHOT 替换为-RC1），这个版本被构建并存储在存储库管理器中，然后部署在我们的UAT env 上。

如果需要一些修复，我们会在同一个 release 分支中创建其他 -RCx 版本，这些工件存档在存储库管理器中，并部署在 UAT 环境中。因此我们可以精确跟踪不同版本中的错误修复。

一旦-RCx 版本被批准，release 分支将被推送到master，更新 pom 以删除 -RCx，构建并存储在存储库管理器中，然后再部署到 PROD 环境中.

但是通过这种方式，在PROD 和UAT 中部署的二进制文件并不完全相同：由于<version> 标记，两个WAR 中的POM 是不同的。 这并不是一个真正的好习惯。

如果我正确理解了 git-flow 模型，“最终”版本号（没有-RCx）应该在创建release 分支时设置，并且相同版本在此分支之前是“活动的”被推到master，对吧？在这种情况下：

我们丢失了UAT 中真正部署的应用程序版本的信息（因为我们丢失了-RCx 标识符，我们可能不知道部署的版本是否包含最后的错误修复，或者它是否是旧版本已部署...） 在存储库管理器中，我们无法知道工件是从release 分支还是从master 构建的，因为在将feature 分支推入@987654349 时版本号不再更改@。

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

你（或者你会）如何使用 git-flow 模型中的 Maven 项目管理Release Candidates？

【参考方案1】：

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

我已将此策略用于多个生产应用程序并且没有遇到任何问题。