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 devoxxfr. After Branching this time it’s about 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.
staging'', production''), and an environment-specific promotion can occur once per build.
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:
https://wiki.jenkins-ci.org/display/JENKINS/Build+Pipeline+Plugin : This plugin offers a very good visualization of the pipeline. By configuring a new Jenkins view and choosing which job is the first job in the pipeline you can get a visualization of the whole acceptance and build promotion pipeline.
https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Trigger+Plugin: The Parameterized Trigger Plugin is another triggering plugin but with a twist: this plugin lets you configure more aspects of the triggering logic
https://wiki.jenkins-ci.org/display/JENKINS/Violations This plug-in generates reports static code violation detectors such as checkstyle, pmd, cpd, findbugs, codenarc, fxcop, stylecop and simian
Here are a few articles about those:
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:
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/ 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 ?