2013-12-19 14 views
0

我们使用artifactory作为回购管理器。我们存储了回购libs-release-local和快照软件包libs-snapshot-local中的发布包。当我们在各种环境中进行bug修复时,artifactory的工件的版本维护

例如:如果我们发送war(Web应用程序)到测试,应该从libs-snapshot-local,如果它是为舞台&督促它会从libs-release-local

我会说一个场景,在这里我需要帮助,下方:

一旦war是测试服务器上认证的好,我们会发送相同的代码阶段。我们在部署到阶段后看到了一个bug,所以我们改变了代码并重新构建它,它显然无法进入相同的版本化版本(如在artifactory中,我们无法重写版本)。

所以,

  1. 如果我们认可10 bug修复一次一个,在每个阶段部署后会发生什么?
  2. 如果我们在完成产品后发现有错误修复,该怎么办?

Artifactory将有大量的文件夹与这么多的版本名称&文件夹。这是不错的做法吗?否则在我们的程序中有什么感觉错误?

谢谢!

+0

我可以知道投票的理由吗?我错过了什么吗? – phoenix

回答

1

建议先阅读Binary repository management Refcard

您需要定义您的文件夹和战争(Web应用程序),这已经是很好用不同回购为不同的目的(快照/释放)你的战略

维护过程很简单

  1. 修复bug,增加版本,发送到libs-snapshot-local进行测试后,测试
  2. ,又名QA过去了,包促进发布/台回购libs-release-local再次供市民使用一次。

在这种情况下,错误修复与正常开发过程相同。

或者您可以改进问题以使问题更清晰。

+0

谢谢你的链接拉里。这很有帮助。但是关于增加版本,我们假设我最初在1.0版本的libs-releases中部署了一场战争,并在部署后发现了一个错误。所以我们进行了代码更改,并通过快照,然后提升到发布下一个版本(比如1.1)。让我们假设我在部署后每次发现8个其他错误。所以这个版本会持续到1.9。这是一个有10个文件夹(1.0 - 1.9)的好程序,还是我们有任何解决方法? – phoenix

+0

取决于是否需要释放具有不同错误修复的战争文件。大多数情况下,它们可以在下一个版本1.1中一起打补丁。此处的版本与版本相关,而不是代码更改。它与您的发布版本策略相关,而不是artifactory工具。 –

+0

@Lary感谢编辑和回答 – phoenix