当我们在各种环境中进行bug修复时，artifactory中工件的版本维护

我们使用

artifactory

作为回购管理器。我们在repo

libs release local

中存储发布包，在

libs snapshot local

中存储快照包

例如：如果我们将

war

（web应用程序）发送到测试中，它应该来自

libs snapshot local

，如果它进入stage&prod，它将来自

libs release local

我会说一个场景，我需要以下帮助：

一旦

war

在测试服务器上被证明良好，我们将向stage发送相同的代码

在部署到stage之后，我们看到了一个bug，所以我们更改了代码并再次构建它，它显然不能转到同一版本的版本（就像在artifactory中一样，我们不能覆盖版本）

所以

在每个阶段的部署之后，如果我们一次识别出10个bug修复，会发生什么

如果我们在进入prod之后意识到存在bug修复，该怎么办

Artifactory将拥有大量具有如此多版本名和文件夹的文件夹。这是好的做法吗？或者在我们的程序中有什么错误

谢谢

建议先阅读

您需要为文件夹和WAR（web应用程序）定义策略，为不同目的使用不同的repo（快照/发布）已经很好了

维护过程很简单

修复错误并增加版本，发送到

libs snapshot local

进行测试

测试后，a.k.a QA通过，软件包升级为发布/阶段回购

libs release local

，再次供公众使用

在这种情况下，bug修复与正常开发过程相同

---

或者，您可以细化问题，使您的问题更加清晰。

我可以知道否决投票的原因吗？我错过什么了吗？谢谢你的链接，拉里。这很有帮助。但关于增加版本，让我们假设我最初在libs版本中部署了一个1.0版本的war，并在部署后发现了一个bug。所以我们做了一个代码更改&它经过快照，然后升级到下一个版本（比如1.1）。让我们假设我在部署之后一次发现了8个其他bug。所以这个版本会一直持续到1.9。这是一个有10个文件夹（1.0-1.9）的好过程，还是我们有解决方法？取决于是否需要发布具有不同错误修复的war文件。大多数情况下，它们可以在下一版本1.1中进行修补。此处的版本与发布相关，而不是与代码更改相关。它与您的发布版本策略有关，而不是与人工工具有关。