Blog

The latest expert opinions, articles, and guides for the Java professional.

Pragmatic Continuous Delivery with Jenkins, Nexus and LiveRebel

Managing Resources

One of the issues we commonly encounter in different stages of manual and automated testing is the fact that the number of environments is limited while the number of builds that can be in progress at the same time is essentially unlimited. This can be solved by using elastic cloud deployment, but even then it’s an unreasonable cost as the process will just bottleneck at a different stage.

Let’s start by creating a clean-up-test job that will be triggered by qa-success and would be responsible for removing the deployment we created in deploy-test.

Unfortunately LiveRebel’s Jenkins plugin does not support undeployment at the moment, but we can use the Command-Line Interface to the same effect:

liverebel/bin/lr-cli.sh -url https://cddemo.zeroturnaround.com:9001/ -token 14a3c156-955b-4934-a500- e19404a76945 undeploy -app lr-demo-B${SOURCE_BUILD_NUMBER} -servers ec54877faf343586263cf4c1d7d03088

liverebel/bin/lr-cli.sh -url https://cddemo.zeroturnaround.com:9001/ -token 14a3c156-955b-4934-a500- e19404a76945 remove -app lr-demo-B${SOURCE_BUILD_NUMBER}

Limiting the number of deployments is a harder problem. Jenkins does provide a Throttle Concurrent Builds Plugin, but it limits the number of builds that can be run at the same time. However, because no builds run during the Manual QA phase, this doesn’t work in our example.

The best solution to be used at the moment is to write a script that would query LiveRebel to find the number of test deploy- ments and delay the build if the max number is up. A companion to this script is a Jenkins job that expires the test deploy- ments after some time. It’s a bit clumsy, but it works.


Business Delivery

The philosophy around Continuous Delivery includes an understanding that new releases should be triggered by the party responsible for the business value that the new version brings. This will probably include at least some staff who you can not exactly expect to find and press a button in Jenkins. Instead we can use email, or even build a custom interface based on the Jenkins REST API.

Let’s create a begin-deploy-production job in Jenkins. First we download the qa-notes and mark the build as a release candidate:

[mvn] org.apache.maven.plugins:maven-dependency- plugin:2.4:get -Dartifact=org.zeroturnaround:lr- demo:B${SOURCE_BUILD_NUMBER}:txt:qa-notes -DremoteRep ositories=cd::::http://127.0.0.1:2002/nexus/content/ repositories/qa/ -Ddest=rc.txt

echo “[RC]” >> rc.txt
echo “Marked as RC” >> rc.txt

[mvn] org.apache.maven.plugins:maven-dependency- plugin:2.4:get -Dartifact=org.zeroturnaround:lr- demo:B${SOURCE_BUILD_NUMBER}:war -DremoteReposit ories=cd::::http://127.0.0.1:2002/nexus/content/ repositories/qa/ -Ddest=lr-demo.war

[mvn] deploy:deploy-file -Durl=http://127.0.0.1:2002/ nexus/content/repositories/rc/ -DrepositoryId=cd
-Dfile=lr-demo.war -Dfiles=rc.txt -Dtypes=txt -Dclassifiers=rc-notes -DgroupId=org.zeroturnaround -Dpackaging=war -DartifactId=lr-demo -Dversion=B${SOURCE_BUILD_NUMBER}

Next we send an email with subject line like:

Release Candidate ready for lr-demo:B${ENV,var=”SOURCE_ BUILD_NUMBER”}

and body text like:

The release candidate passed all tests and ready to be de- ployed to production.

Just click this link to deploy it to production!

http://host:port/job/deploy-production/ buildWithParameters?SOURCE_BUILD_ NUMBER=${ENV,var=”SOURCE_BUILD_NUMBER”}

If you want to do it nicer, you can provide a dedicated interface with a big red button or even put a physical button on management’s desk:

big red button

You can get one from Amazon, but it will only work on Windows OS.


DOWNLOAD THE PDF

No Responses

No comments yet.

RSS feed for comments on this post.

Leave a comment