java - 如何在提升基础 ci 环境中处理项目的 jira 版本和 maven 版本控制

Question

在我们公司，我们目前有5个环境

1. 本地：开发者的计算机
2. 集成：所有开发人员都可以使用服务器，以收集下一个版本的开发并验证它们
3. 功能性：我们的产品负责人可以使用，这样他就可以断言他要求的功能是可以的
4. 基准测试：为了断言我们没有在性能中添加回归
5. 制作：终于！

我们的部署策略基于促销：当我们想要交付当前构建时，我们执行发布并在功能环境 (3) 上交付它。如果经过验证，我们将相同的捆绑包推广到 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 不同的包来引入风险。

我们觉得我们错过了一些东西。你做什么工作 ？你遇到过这个版本的问题吗？你是怎么处理的？

谢谢

标签： javamavencontinuous-integrationversionjira

Answer 1

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

1. 您只管理 Jira 票证中版本的前两部分（如2.0），因此您可以轻松调整错误修复编号。这要求您在每次进行新计划时提高第二个数字。

2. 部署新版本时，您始终会更改 Jira 票证中的编号。这可以通过 REST 完成，这样您就可以避免手动错误。