4

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

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

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

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

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

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

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

  • 我们丢失了应用程序实际部署在哪个版本的信息UAT（因为我们丢失了-RCx标识符，我们可能不知道部署的版本是否包含最后的错误修复，或者它是否是部署的旧版本......）
  • 在存储库管理器中，我们无法知道是从release分支还是从构建工件master，因为在将feature分支推送到master.

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

您（或您将如何）在 git-flow 模型中使用 Maven 项目管理候选版本？

4

1 回答 1

0

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

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

于 2018-03-22T17:35:15.543 回答