快照仓库和发布仓库的使用有何不同？

Question

我知道在开发过程中，构建出来的产物会被放在快照仓库中。

当产品需要进入QA阶段进行测试时，团队是从快照仓库拉取还是完整构建后部署到发布仓库再交给QA？

此外，如果我的快照仓库保存了每个构建的所有构件，那么这通常如何清理？可以保留构建服务器上的最近5个构建，但不用保存所有构建。我正在使用Artifactory。

- DonBecker

Answer 1

意见不一，这是我的方法：

快照用于开发

通常用于“临时”构建。我从CI服务器发布它们，触发源代码提交的更改。快照构建的目的是共享特定团队的最新已测试工件。这很重要，因为团队之间可能会共享JAR包。

这种方法比我们以前共享源代码的方法要稳定得多（当另一个团队提交失败的构建时，会出现不断的火灾问题....因此也会影响其他人）。

清理快照

我使用Nexus来管理我的存储库，它有一个定期清除快照存储库的计划任务，可以进行配置。我想Artifactory也有类似的功能。

发布候选版本用于QA

我像对待客户的完整发布一样对待QA。这就是为什么我更喜欢术语“发布候选版本”的原因。

发布候选版本构建与快照的关键区别在于源代码被“标记”或“标签化”（取决于您的SCM系统的术语）。你正在做的是在沙滩上画一条线，从这里你可以方便地随时重新创建二进制文件。

Nexus professional有一个暂存套件，使开发人员能够剪切新版本并将其保存在临时的“暂存库”中。显然，某些版本将无法通过测试，这些版本将被删除。其他版本将被推广到链中的下一组或发布到公共区域。

有几种实现此“推广模型”发布管理的方法。

如何管理发布修订版

我使用以下编号约定来进行发布。

<major number>.<minor number>.<patch number>.<build number>

Example:
1.0.0.24

对于较小/简单的项目，我可能会改变惯例并省略修补程序号。

Ivy有一个非常有用的buildnumber任务，可以管理递增的构建号，基于已经发布到您的存储库中的内容。

<property name="release.candidate" value="1.0.0"/>
..
<ivy:buildnumber organisation="${ivy.organisation}" module="${ivy.module}" revision="${release.candidate}"/>
..
<echo message="Release revision: ${ivy.new.revision}"/>

release.candidate 属性通常存储在版本控制下的属性文件中。我真正喜欢这个解决方案的原因是它可以实现并行分支管理（请参阅此问题的答案）。

- Mark O'Connor