您如何在基于促销的 ci 环境中处理项目的 jira 版本和 maven 版本[关闭]

Posted 2023-02-18

【中文标题】您如何在基于促销的 ci 环境中处理项目的 jira 版本和 maven 版本[关闭]

【英文标题】：How do you handle jira version and maven versionning of your project in a promotion base ci environment [closed]

【发布时间】：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 不同的包来引入风险。

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

谢谢

【参考方案1】：

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

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

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