I discussed the Jenkins Promoted Build Plugin in a few recent blog post , when talking about the QA Process and Beta Test Distribution for mobile apps, where I gave a simple scenario of how it could be used to help control the testing lifecycle for application builds. I happened to run through this with my friend Andrew Phillips from XebiaLabs, and he suggested some improvements to that scenario that I thought people might like to see, so I reworked the online example to illustrate those ideas. Thanks also (as always) to Kohsuke Kawaguchi for his help and suggestions. By the way, if you are interested in this and other enterprise-scale features of Jenkins, then please join Andrew and I for a XebiaLabs and CloudBees joint webinar on Wednesday November 7th: Setting up Continuous Delivery with Jenkins Enterprise and DeployIt. ****
For this scenario, we have four Jenkins jobs, two which are "owned" by the developer and two which are "owned" by QA and Release Management. The developer pushes code changes to a Git repository and that triggers the initial build job (cuckoochess-android): this job has a build promotion configured (Release to QA), which depends on a successful build/test plus a downstream build (cuckoochess-android-matrix) that checks for compatibility with older versions of the Android SDK. As far as the developer is concerned, he or she is really only interested in the outcome of the initial app build/test but until the downstream multi-configuration test build completes, the build isn't ready to go for QA review so the Promotion Status shows like this:
Once the downstream matrixed build(s) run successfully (and in reality we would expect to see a range of other tests including automated functional and touch tests), the build is automatically promoted and is ready for QA review and the Promotion Status now looks like this:
The remaining two build jobs are managed by the QA and Release Management teams: these are gated by a second build promotion (CuckooChess QA Approval). A third Jenkins job (cuckoochess-android-QA) is triggered by the Release to QA build promotion, like so:
and the only qualification (in this example) is a manual approval by a named QA reviewer, which is configured like this:
The QA reviewer would usually want to look at unit test results, code coverage and quality metrics reported by tools like JUnit, Cobertura/Emma, Android Lint or one or more of the many code quality tools supported by the Jenkins Violations Plugin . Many users probably prefer to have as much as possible of this quality and test coverage checking automated using Jenkins and it is common to set thresholds that must be achieved before a build can be accepted. You can see an example of how to configure this sort of reporting for an Android build here, described in more detail in this blog . Either way, the cuckoochess-android-QA job will show its Promotion Status like this, until a manual approval is given (by logging on to Jenkins, viewing the build and clicking Accept):
Once the QA reviewer is happy and the manual approval has been given, then the QA Approval build promotion will run, which in this case triggers the final build job (cuckoochess-android-release) which pushes the approved build to Zubhium for beta test distribution as described in the earlier blog. The final build promotion status of the cuckoochess-android-QA job is now:
The final piece of the puzzle is how to ensure that the build that finally gets pushed to Zubhium for beta testing is the right one: we need to make sure that the application archive that goes out contains the exact bits that were built by the original cuckoochess-android job. The way to configure that is by using the Jenkins Copy Artifacts Plugin to get the .apk application archive from the cuckoochess-android project, using a permalink to specify that we want the build associated with the most recent Release to QA build promotion. That configuration looks like this: