Back from Devoxx - Part 2 - Dev-QA-Ops Thoughts - About Build Promotion

First published on April 22 2013 and tagged Tech . Java .

Here are some more notes and various pointers on software engineering quality, continuous delivery and dev-qa-ops practices gathered-at or inspired-by the various chats I had at devoxxfrimage. After Branchingimage this time it’s about build promotion

Build promotion:

Build promotion:

Build promotion is an indication that a given build has been approved for deployment to a certain environment.
Just as a release may have many builds, a build may have several promotions. As the commonplace definition implies, promotions occur in a linear direction towards production (e.g. integration'', testing'', staging'', production''), and an environment-specific promotion can occur once per build.

Jenkins can help

Jenkins offers a plugin for this:

This plugin can be combined with others and provide a powerfull and yet flexible solution
these other useful plugins are:

Here are a few articles about those:

Your artifact repository can also be leveraged

Artifactory supports build promotion to some extent in its commercial version, using REST APIs.

In Nexus Pro you can set up a Staging profile, which intercepts certain artifacts and places them in a special, dynamically-created repository.

Once all the required artifacts are deployed, a build administrator can make these staged artifacts available for further testing (in a UAT environment, for example).

Involved users can be notified when a build is staged and promoted, so that they can go to the relevant environment and run their own tests.

When the tests are finished, the artifacts in the staging repository can be promoted to their final destination (for example, a special Production Releases repository). You can also associate rules with this promotion process. These rules are highly configurable.

docs and pointers:

Is the maven release plugin and process in the way?

The maven release plugin is in the way of implemeting build promotion:

  • The Maven release plugin states: You build a new release when a snapshot build is good enough

  • When build promotion and Continuous Delivery states: Any build is a potential release

Should we stop using snapshots versions and use alternatives like the maven versions plugin http://mojo.codehaus.org/versions-maven-plugin/image to increment the version at every build and hence make every resulting artefact a candidate to production ?

Or when we are making distrubutable software, should we just deal with snapshots and don’t bother with the whole maven release process nor plugin ?

cf.