我了解在开发过程中构建工件被放置在快照存储库中。
当产品需要去 QA 进行测试时，团队是否从快照存储库中提取？还是他们做一个完整的构建，部署到发布存储库，然后从那里把它交给 QA？
此外，如果我的快照存储库包含来自每个构建的所有构建工件，那么这通常是如何清理的？我可以看到保留来自构建服务器的最后 5 个构建，但不是每个构建。如果有帮助，我正在使用 Artifactory。
问问题
7616 次
1 回答
18
意见不同，这是我的方法：
快照用于开发
通常用于“一次性”构建。我从我的 CI 服务器发布它们，由提交到源代码的更改触发。快照构建的目的是共享来自特定团队的最新测试工件。这很重要，因为团队可能会在彼此之间共享 jar。
这种方法比我们以前共享源代码的方法稳定得多（持续的灭火问题，当另一个团队提交的东西未能成功构建时......以及其他所有人的扩展）。
清理快照
我使用 Nexus 来管理我的存储库，它有一个可以配置为定期清除快照存储库的计划任务。我想 Artifactory 有类似的功能。
候选版本用于 QA
我将 QA 视为对客户的全面发布。这就是为什么我更喜欢“Release Candidate”这个词。
发布候选版本和快照之间的主要区别在于源代码是“标记的”或“标记的”（取决于您的 SCM 系统的术语）。您正在做的是在沙子上画一条线，您可以方便地根据需要重新创建二进制文件。
Nexus 专业版有一个staging suite，它使开发人员能够剪切一个新版本并将其保存在一个临时的“staging repository”中。显然，某些版本将无法通过测试，在这种情况下它们会被丢弃。其他人要么被提升到链中的下一个组，要么被释放到公共区域。
有几种方法可以实现这种发布管理的“促销模型”。
如何管理版本修订
我对我的版本使用以下编号约定。
<major number>.<minor number>.<patch number>.<build number>
Example:
1.0.0.24
（对于更小/更简单的项目，我可能会更改约定并删除补丁号）。
Ivy 有一个非常有用的buildnumber任务来管理递增的 build number，基于已经发布到你的存储库的内容。
<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属性通常存储在属性文件中，受版本控制。我真正喜欢这个解决方案的地方在于它支持并行分支管理（请参阅此问题的答案）。
于 2011-12-10T12:51:34.710 回答