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

问题描述

我理解在开发过程中，构建工件放置在快照存储库中。

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

当产品需要转到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?

另外，如果我的快照仓库包含所有的构建工件，每个build，这是怎么清除掉的呢？我可以看到保持最后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服务器发布它们，由提交到源代码的更改触发。快照构建的目的是共享来自特定团队的最新测试工件。这很重要，因为团队可能在彼此之间共享瓶子。

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.

吹风释放给客户。这就是为什么我喜欢术语释放候选人。

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屋！