在我们公司，我们目前有 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 不同的捆绑包来引入风险。
我们觉得我们错过了什么。你是做什么工作的？您是否遇到此版本问题？你是怎么处理的？
谢谢
我能想到的两种可能的方法：
-
您只需在 Jira 票证中管理版本的前两部分(如
2.0(，因此您可以轻松调整错误修复编号。这要求您在每次进行新计划时提高第二个数字。 -
部署新版本时，您始终会更改 Jira 票证中的编号。这可以通过 REST 完成，这样您就可以避免手动错误。