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

Question

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

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

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

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

批准-RCx版本后，release分支将推送到master，更新pom以删除-RCx，构建并存储在存储库管理器中在部署到PROD env。

之前

但是通过这种方式，PROD和UAT中部署的二进制文件并不完全相同：2个WAR中的POM不同，因为{{1 }} 标签。 这不是一个好习惯。

如果我正确理解了git-flow模型，那么＆＃34; final＆＃34;应在创建<version>分支时设置版本号（不带-RCx），同一版本为＆＃34; alive＆＃34;直到这个分支被推到release，对吗？在这种情况下：

• 我们丢失了master中实际部署的应用程序版本的信息（因为我们丢失了UAT标识符，我们可能不知道部署的版本是否包含最后一个错误修正或是否包含部署的旧版本...）
• 在存储库管理器中，我们无法知道是否已经从-RCx分支或release构建了工件，因为在推送{{1}时不再更改版本号分支到master。

什么更好？这两种做法有哪些优点/缺点？ （不同的envs -vs上没有相同的二进制文件 - 没有明确的候选版本。）

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

Answer 1

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

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