我了解在开发过程中将构建工件放置在快照存储库中。
当产品需要进行质量检查进行测试时，团队是否会从快照存储库中提取？还是他们进行了完整的构建，部署到发布存储库，然后从那里进行质量检查？
另外，如果我的快照存储库包含每个构建中的所有构建工件，通常如何清理？我可以看到保留了构建服务器中的最后5个构建，但不是每个都保留。如果有帮助，我正在使用Artifactory。
最佳答案
意见不同，这是我的方法：
快照适用于开发人员
通常用于“一次性”构建。我是通过对源代码所做的更改触发的，从CI服务器发布它们的。快照构建的目的是共享特定团队中经过测试的最新工件。这很重要，因为团队之间可能会共享jar。
这种方法比我们以前共享源代码的方法（不断发生的消防问题，当另一个团队提交的东西导致其构建失败……以及扩展到其他所有人）稳定得多。
清理快照
我使用Nexus来管理我的存储库，它具有一个scheduled task，可以将其配置为定期清除快照存储库。我猜想Artifactory具有类似的功能。
候选版本用于质量检查
我将质量检查视为对客户的全面发布。这就是为什么我更喜欢“候选发布”一词的原因。
候选发布版本和快照之间的主要区别在于源代码是“带标签的”或“带标签的”（取决于SCM系统的术语）。您正在做的是在沙子上画一条线，从中可以方便地按需重新创建二进制文件。
Nexus Professional具有staging suite，可让开发人员剪切新版本并将其保存在临时的“暂存库”中。显然，在某些情况下，某些发行版将无法通过测试。其他人则被提升为产业链中的下一个群体，或者被释放到公共场所。
有几种方法可以实现此版本管理的“促销模型”。
如何管理版本修订
我在发布中使用以下编号约定。
<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属性通常存储在版本控制下的属性文件中。我对该解决方案的真正满意之处在于，它支持并行分支管理（请参见this question的答案）。
关于continuous-integration - 快照和发布存储库的使用方式有何不同？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/8452710/