快照和发布存储库的使用方式有何不同?

Don*_*ker 14 continuous-integration ivy artifactory continuous-deployment

我知道在开发过程中,构建工件会放在快照存储库中.

当产品需要进行QA测试时,团队是否会从快照存储库中提取?或者他们是否进行完整构建,部署到发布存储库,然后从那里将其提供给QA?

此外,如果我的快照存储库包含每个构建的所有构建工件,那么这通常如何清理?我可以看到从构建服务器保留最后5个构建,但不是每个构建服务器.如果有帮助,我正在使用Artifactory.

Mar*_*nor 18

意见不同,这是我的方法:

快照适用于Dev

通常用于"一次性"构建.我从我的CI服务器发布它们,由提交给源代码的更改触发.快照构建的目的是共享来自特定团队的最新测试工件.这很重要,因为团队可能在彼此之间共享罐子.

这种方法比我们之前共享源代码的方法稳定得多(恒定的消防问题,当另一个团队提交的东西无法构建时......并且扩展了所有人).

清理快照

我使用Nexus来管理我的存储库,它有一个计划任务,可以配置为定期清除快照存储库.我认为Artifactory具有类似的功能.

发布候选人是QA

我将质量保证视为对客户的全面发布.这就是为什么我更喜欢"候选人"一词.

发布候选版本和快照之间的主要区别在于源代码被"标记"或"标记"(取决于您的SCM系统的术语).您正在做的是在沙子中画一条线,您可以根据需要方便地重新创建二进制文件.

Nexus professional拥有一个临时套件,它使开发能够削减新版本并将其保存在临时"临时存储库"中.显然有些版本将无法通过测试,在这种情况下它们会被丢弃.其他人要么被提升到链中的下一个群体,要么被释放到公共区域.

有几种实现发布管理"促销模型"的方法.

如何管理版本修订

我为我的版本使用以下编号约定.

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

Example:
1.0.0.24
Run Code Online (Sandbox Code Playgroud)

(对于较小/较简单的项目,我可能会改变约定并删除补丁号).

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}"/>
Run Code Online (Sandbox Code Playgroud)

release.candidate属性通常存储在一个属性文件,版本控制之下.我真正喜欢这个解决方案是它支持并行分支管理(请参阅这个问题的答案).