【发布时间】：2020-04-03 09:14:45
【问题描述】：
我们公司目前有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 不同的包来引入风险。
我们觉得我们错过了一些东西。你做什么工作 ？你遇到过这个版本的问题吗？你是怎么处理的？
谢谢
【问题讨论】：
标签： java maven continuous-integration version jira