快照和发布存储库的使用有何不同? [英] How are snapshot and release repositories used differently?

问题描述

我了解在开发过程中构建工件被放置在快照存储库中.

I understand that during development build artifacts are placed in the snapshot repository.

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

When a product needs to go to QA for testing, do teams pull from the snapshot repository? Or do they do a full build, deploy to the release repository, and then give it to QA from there?

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

Also, if my snapshots repository holds all the build artifacts from each build, how is this commonly cleaned up? I could see keeping the last 5 builds from the build server, but not every one. I'm using Artifactory if it helps.

推荐答案

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

Opinions differ, here'e my approach:

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

Typically used for "throwaway" builds. I publish them from my CI server, triggered by changes committed to the source code. The purpose of the snapshot build is to share the latest tested artifact from a particular team. This is important as teams might be sharing jars between each other.

这种方法比我们以前共享源代码的方法要稳定得多(不断出现的消防问题，当另一个团队提交一些使他们的构建失败的事情......以及其他人).

This approach is much more stable than our previous approach of sharing the source code (Constant fire-fighting problems, when another team commits something that fails their build.... and by extension everyone elses).

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

I use Nexus to manage my repository, it has a scheduled task that can be configured to periodically purge the snapshot repository. I'd imagine Artifactory has similar functionality.

我将 QA 视为对客户的全面发布.这就是为什么我更喜欢发布候选人"这个词.

I treat QA like a full-blown release to the customer. That's why I prefer the term "Release Candidate".

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

The key difference between a release candidate build and a snapshot is that the source code is "tagged" or "labelled" (dependent on your SCM system's terminology). What you're doing is drawing a line in the sand from which you can conveniently re-create the binary on demand.

Nexus 专业人士有一个 临时套件，它使开发人员能够剪切新版本并将其保存在临时临时存储库"中.显然，某些版本将无法通过测试，在这种情况下它们会被删除.其他人要么晋升到链中的下一组，要么发布到公共区域.

Nexus professional has a staging suite, which enables development to cut a new release and hold it on a temporary "staging repository". Obviously some releases will fail testing in which case they're dropped. others are either promoted to the next group in the chain, or released to the public area.

有几种方法可以实现这种发布管理的推广模型".

There are several methods of implementing this "promotional model" of release management.

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

I use the following numbering convention for my releases.

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

Example:
1.0.0.24

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

(For smaller/simpler projects I might alter the convention and drop the patch number).

Ivy 有一个非常有用的 buildnumber 任务来根据已发布到您的存储库的内容管理递增的内部版本号.

Ivy has a wonderfully useful buildnumber task to manage the incrementing build number, based on what has already been published to your repository.

<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 属性通常存储在版本控制下的属性文件中.我真正喜欢这个解决方案的是它支持并行分支管理(参见 这个问题).

The release.candidate property is typically stored in a properties file, under version control. What I really like about this solution is that it enables parallel branch management (See answer to this question).

这篇关于快照和发布存储库的使用有何不同?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！