How are snapshot and release repositories used differently?

Question

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

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?

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.

Answer 1

Opinions differ, here'e my approach:

Snapshots are for Dev

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).

Cleaning up snapshots

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.

Release candidates are for QA

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

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 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.

How release revisions are managed

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 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}"/>

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).