快照和发布存储库的使用方式有何不同?
Posted
技术标签:
【中文标题】快照和发布存储库的使用方式有何不同?【英文标题】:How are snapshot and release repositories used differently? 【发布时间】:2012-01-17 04:07:09 【问题描述】:我了解在开发过程中构建工件被放置在快照存储库中。
当产品需要进行 QA 测试时,团队是否会从快照存储库中提取?还是他们进行完整构建,部署到发布存储库,然后从那里将其交给 QA?
另外,如果我的快照存储库包含来自每个构建的所有构建工件,这通常是如何清理的?我可以看到保留来自构建服务器的最后 5 个构建,但不是每个构建。如果有帮助,我正在使用 Artifactory。
【问题讨论】:
【参考方案1】:意见不同,这是我的方法:
快照供开发人员使用
通常用于“一次性”构建。我从我的 CI 服务器发布它们,由提交到源代码的更改触发。快照构建的目的是分享来自特定团队的最新测试工件。这很重要,因为团队可能会在彼此之间共享 jar。
这种方法比我们之前共享源代码的方法稳定得多(持续的灭火问题,当另一个团队提交的东西未能成功构建时......以及其他所有人的扩展)。
清理快照
我使用 Nexus 来管理我的存储库,它有一个 scheduled task,可以配置为定期清除快照存储库。我想 Artifactory 也有类似的功能。
候选版本用于 QA
我将 QA 视为对客户的全面发布。这就是为什么我更喜欢“Release Candidate”这个词。
发布候选版本和快照之间的主要区别在于源代码被“标记”或“标记”(取决于您的 SCM 系统的术语)。您正在做的是在沙地上画一条线,您可以方便地根据需要重新创建二进制文件。
Nexus 专业人士有一个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 的回答)。
【讨论】:
以上是关于快照和发布存储库的使用方式有何不同?的主要内容,如果未能解决你的问题,请参考以下文章
SQL Server中使用数据库快照的方式来完成测试环境中数据库的轻量级备份还原操作
在 IEEE 754 和 JavaScript 中,0 和 -0 的表示方式有何不同?