Blog

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

Pragmatic Continuous Delivery with Jenkins, Nexus and LiveRebel

Example: Live Chat Application

To demonstrate the do’s and don’ts of the CD pipeline we’ve built a persistent Live Chat application.

Live chat application do's and don'ts CD pipeline

This application is deployed in 2 different environments:

Testing
1x Apache Tomcat
1x Redis

Production
2x Apache Tomcat
1x Apache /w mod_proxy
1x Redis

The production environment is under load using traffic simulated by JMeter (http://jmeter.apache.org/), and the other environments are used for testing purposes.


VCS & Artifact Repository

The starting point of the CD pipeline is the Version Control System. It enables developers to collaborate on the code and manages the changes/patches/commits/changesets (hereinafter called “patches”) that start the pipeline.

Using a Distributed VCS (DVCS) like Git or Mercurial is suggested to allow easier collaboration, including effortless branching and merging. However, there is no requirement to use DVCS and CD can be used with Subversion or even CVS. In the end, every patch figuratively enters the pipeline and results in a release candidate if it passes it successfully.

The Artifact Repository – in this case Nexus – serves as the synchronization point in the workflow to allow long-term storage and tracking as well as manual or long-running processes. Every successful completion of the CD stage should deploy an artifact to the corresponding repository.

Using the artifact repository in such a manner lets us easily incorporate manual stages (e.g. manual QA when finished deploys an artifact) and leaves a trail of artifacts that have passed various stages of the CD pipeline. It is also an additional guard against errors in the flow, as the next stage cannot start unless the artifact is deployed to the previous repository.

For our example application we use a Mercurial repository and you can clone it from: https://bitbucket.org/ekabanov/cd-live-chat

For the purposes of this example, we will clone the repository and do local changes that will initiate the CD process.

close repository local changes initiate CD process

We have also created several local repositories corresponding to each stage of the CD pipeline:

/repos/build/
/repos/test/
/repos/qa/
/repos/rc/

The “RC” name stands for Release Candidate and reflects the fact that the artifact is ready to be deployed to production, rather than it has been or should be deployed. This is one of the key differences between
Continuous Delivery and Continuous Deployment. The latter calls for automatically triggered releases, whereas the former just calls for a release-ready state, delegating the actual release decision to other decision makers.

Note that we do not create the Stage repository. We will not cover the Stage part of the pipeline in this paper, as it is derivative of the Test, QA and Production parts.

Sonatype Nexus repository manager

Here we use the Sonatype Nexus repository manager, although others like JFrog Artifactory and Apache Archiva will work just as well.

Orchestration Service

The goal of every CD pipeline should be to enable an automated, trackable workflow. We need an orchestration service to manage that workflow, invoking various stages and managing the decision points. Luckily, such requirements have existed for a long while in the Continuous Integration world, so we can use one of the mature and feature-rich CI servers.

We use the Jenkins CI server, because it is by far the most popular, reaching 49% market penetration. Popular alternatives include Atlassian Bamboo and JetBrains TeamCity.

We will initially create only the first three jobs — build, which produces an artifact, deploy-test, which deploys it to the Test environment and automatic-tests, which runs tests on that environment. The build step is a part of the Build stage, while the next two steps are a part of the Test stage, even though there isn’t a great way in Jenkins to bring that out. To have an overview of the step and builds in-progress we will use the Jenkins Build Pipeline Plugin:

orchestration service build pipeline view Jenkins plugin


DOWNLOAD THE PDF

No Responses

No comments yet.

RSS feed for comments on this post.

Leave a comment