Java 如何在基于升级的ci环境中处理项目的jira版本和maven版本

我们公司目前有5个环境

本地：开发人员的计算机

集成：服务器可供所有开发人员使用，以便收集下一版本的开发并验证它们

功能性：可供我们的产品负责人使用，以便他可以断言他所要求的功能是正常的

基准测试：为了表明我们没有在性能中添加回归

制作：终于 我们的部署策略基于升级：当我们想要交付当前构建时，我们执行一个发布，并在功能环境上交付它（3）。如果经过验证，我们将同一个bundle升级到benchamrks env（4），如果一切正常，则升级到生产（5）

我们目前正在尝试使用版本管理来管理Jira仪表板中的功能。 例如，我们的目标是2.0.0版的下一个版本

所以想象一下，我们到达了开发人员的终点。我们正在开发一个2.0.0-SNAPSHOT捆绑包。该捆绑包在本地（1）和我们的集成环境（2）上都可用。 为了将我们的开发人员交付给功能和基准环境，我们执行了2.0.0版。 如果在这些环境中发现任何问题，这意味着我们需要部署修复程序，因此我们需要部署2.0.1版本。也许我们错过了太多东西，以至于我们最终能够用2.0.52版将捆绑包推广到生产环境中

这里，我们有一个问题：Jira的目标是2.0.0版，而我们交付了2.0.52版

我们的第一个解决方案是使用rc限定符。这意味着我们已经达到并交付了版本2.0.0-rc52。但它对我们来说并不合适，因为它仍然是一个“候选版本”，而不是一个版本。 另一个解决方案是将2.0.0-rc52交付到我们的基准环境（4）。由于该捆绑包已经过验证，并且我们的PO希望它投入生产，因此我们从2.0.0-rc52标签中执行了一个新版本，以将2.0.0捆绑包交付生产。但我们打破了我们的促销体系，通过生成与2.0.0-rc52不同的捆绑包引入了风险

我们觉得我们错过了什么。你是做什么的？您是否遇到此版本问题？你是怎么处理的

---

谢谢

我能想到两种可能的方法：

您只管理Jira记录单中版本的前两部分（如

2.0

），因此您可以轻松地调整错误修复编号。这要求您在每次执行新计划时提高第二个数字

当部署新版本时，您总是更改Jira票证中的编号。这可以通过REST来完成，从而避免手动错误