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

Pragmatic Continuous Delivery with Jenkins, Nexus and LiveRebel

Automated- Test Job

This job should run an acceptance test on the test deployment to verify it. We will only use a crude test for demonstration purposes, but in a real app you would use JUnit, Selenium, Arquillian and other useful tools to make sure that the app version is in good working order.

To start, we will download the WAR and build notes from the previous stage:

[mvn] org.apache.maven.plugins:maven-dependency-plugin:2.4:get

[mvn] org.apache.maven.plugins:maven-dependency-plugin:2.4:get
-DremoteRepositories=cd:::: -Ddest=test.txt

Next we run the “test” and update the build notes:

echo “[TEST]” >> test.txt
echo “Jenkins URL: ${BUILD_URL}” >> test.txt
wget “http://localhost:8080/lr-demo-B${SOURCE_BUILD_NUMBER}/api/success” >> test.txt
echo “Automated Tests Passed!!!” >> test.txt

Notice that we change the classifier from “build-notes” to “test-notes”. This is essential to avoid clashes in the local Maven repository.


So far we have defined three Jenkins jobs, but no relations among them. Jenkins still has some way to go before getting awesome at wiring things together; aside from the Build Flow plugin, whose documentation we found tricky, the only way to start the next job is to have either an explicit dependency or an explicit trigger.

Therefore, for the build job, we’ll add the following post-build step:

Wiring build job post-build steps

We start deploy-test explicitly and pass it a $SOURCE_BUILD_NUMBER parameter that just uses the current $BUILD_NUMBER. This is necessary so we can use the original build number as the version throughout the pipeline.

The deploy-test job triggers automated-tests similarly:

Wiring deploy test job triggers automated

Note: We don’t need to pass the parameter explicitly as deploy-test was triggered with the same parameter. The same applies further down the pipeline.

Delivery Manager

Delivery Management is a comparatively new concept. This is mainly because until now the actual delivery of the application to production without downtime was either impossible or required a lot of manual work and headaches on behalf of the Ops team. Although there are ways to script the deployment in a semi-automated way we decided to use LiveRebel instead for the following reasons:

No Downtime: LiveRebel will choose whether to hotpatch the applica- tion online or do a rolling session drain, but either way the users can keep on their work.

Failure Management: LiveRebel always takes the application from consistent state to consistent state and makes sure that any update you do can be rolled back with a single button push.

Ecosystem Support: Any app, any server, any source. Not just Tomcat!

Exact Knowledge: LiveRebel shows exactly what is deployed, where, how and by whom.

Zero Configuration: You can start using LiveRebel inside 5 minutes, without any docs.

This ties well with the tenets of CD, since we can get the production deployment just as predictable and manageable as the rest of the pro- cess and eliminate human intervention without fear.

Delivery Manager LiveRebel continuous delivery production deployment

LiveRebel alternatives include Cargo, Jenkins Deploy plugin or just scripting the native tools that containers provide.


No Responses

No comments yet.

RSS feed for comments on this post.

Leave a comment