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

Pragmatic Continuous Delivery with Jenkins, Nexus and LiveRebel

Build Job

The build job starts by doing a checkout of the Mercurial repository:

build job Mercurial repository source code management

Once that is done, we can run the Maven build (further on we’ll show Maven and shell commands without the screenshot):

build job Maven invoke targets

Notice that we pass $BUILD_NUMBER to the build. $BUILD_NUMBER is a built-in Jenkins environment variable which resolves to the number of the build. By overriding the app version on the command line, we insure that the artifact can be traced back to the build that created it.

Next, we upload the ready artifact to the Build repository:

[mvn] deploy:deploy-file
-DrepositoryId=build -Dfile=target/lr-demo.war -Dfiles=build.txt
-Dtypes=txt -Dclassifiers=build-notes -Dpackaging=war
-DgroupId=org.zeroturnaround -DartifactId=lr-demo

Uh-oh! What is this “build.txt” and why is it uploaded with the artifact?

Well, if you remember, Record is one of the key tenets of CD. Although the history is preserved in Jenkins, our primary deliverables are the artifacts deployed to stage repositories. Thus we’d like to have the information on the build also present in the repository. Some artifact repositories, such as Artifactory from JFrog, support saving such information out-of-the-box with dedicated Jenkins plugins, but we can also just generate and upload a text file that describes the build.

echo “[BUILD]” > build.txt
echo “Build: ${BUILD_NUMBER}” >> build.txt
echo “Jenkins URL: ${BUILD_URL}” >> build.txt
echo “Hg revision: ${MERCURIAL_REVISION}” >> build.txt
echo “Hg log:” >> build.txt
hg log -r ${MERCURIAL_REVISION} >> build.txt

Using shell scripts we save information about the build, including the number, Jenkins build URL, Mercurial revision and even the commit message to the “build.txt” file and then upload it to the Maven repository along with the artifact. This means that whenever something fails, the repository will contain all the information about the artifact. The ready “build.txt” looks like this:

Build: 116
Jenkins URL: http://localhost:2001/job/build/116/
Hg revision: 918894d22205c2471bb22220a0db1041f84e94c6
Hg log:
changeset: 10:918894d22205
tag: tip
user: Jevgeni Kabanov
date: Fri Jun 01 15:14:41 2012 +0300
summary: Added /success for test purposes

Deploy- Test Job

Cool – now we have an artifact. But for it to be useful, we need to deploy it to the testing environment and get those automated tests crunching. Because multiple builds can run in parallel, we need multiple versions to be deployed side-by-side for the automated and manual tests to progress.

Since we have used LiveRebel for staging and production delivery in this article, we will also use it for the tests, although in this case using the Jenkins Deploy plugin would work just as well (at least with Apache Tomcat). The benefits of LiveRebel is that it supports a much wider array of application servers and ensures that OutOfMemoryError never occurs.

We start by downloading the artifact from the Build repository to guarantee correctness.

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

We will discuss the origin of the “${SOURCE_BUILD_NUMBER}” variable when we discuss wiring jobs a little later.

Next we deploy the artifact to the chosen server:

deploy artifact to chosen server with LiveRebel

This deploys the current app build to a unique URL formed like http://host:port/lr-demo-BXXX, where XXX refers to the build number. Notice that “build.txt” is attached to the deployment and thus needs to be downloaded.


No Responses

No comments yet.

RSS feed for comments on this post.

Leave a comment