The latest expert opinions, articles, and guides for the Java professional.
Example: Live Chat Application
To demonstrate the do’s and don’ts of the CD pipeline we’ve built a persistent Live Chat application.
This application is deployed in 2 different environments:
1x Apache Tomcat
2x Apache Tomcat
1x Apache /w mod_proxy
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.
We have also created several local repositories corresponding to each stage of the CD pipeline:
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.
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 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:
No comments yet.
Leave a comment