Continuous Delivery (CD)

Continuous Delivery (CD) expands upon continuous integration by deploying all code changes to a testing environment after the build stage. When continuous delivery is implemented in place, we will always have a Deployment-ready build artifact that has passed through a standardised test process.

I am going to give a generic logical flow of a Delivery Pipeline where everything gets automated for seamless delivery. However, this flow may vary from organisation to organisation as per the requirement.

Let’s assume that we have 3 deployment environments (Development, Staging/QA and Production), then a typical delivery pipeline would have the following steps:

  1. Developer develop and commits the code changes to Version Control System tools like Git.
  2. Continuous Integration/Delivery automation servers like Jenkins pulls this code from the repository using the Git like plugin and build it using build tools like Ant or Maven or MSBuild and runs the unit tests.
  3. After this, same code base passes through static code analysis, An artifact is created, with a unique version number, and will be published to an artifact repository tools like Nexus.
  4. Configuration management tools like Chef provisions testing environment & deploys the app & then Jenkins, chef together releases the same code onto different Test environments on which testing is done using test automation tools like Selenium.
  5. Once the code is tested, the same code will be send for deployment on to the production server at a defined schedule.
  6. After deployment, it is continuously monitored by the tools like Nagios.

Achieving Continuous Deployment (CD) as part of DevOps Practices:
We can achieve CD in 2-ways depending on the requirement.
1. Using Jenkins alone without using any Configuration Management Tools like Puppet/Chef/Ansible.
2. Using Jenkins and Configuration Management Tools like Puppet/Chef/Ansible.

Lets see both one by one with a Java Application with Maven (you may use .Net with MS Build)…

For the next steps, I assume, you have a a Jenkins instance and a remote Tomcat Server up and running with administrator privileges.
1. Continuous Deployment with Jenkins & without using Chef:  By deploying war file from Jenkins to remote Tomcat Server of Staging/QA environment .

Step 1. Generate & Archive the Artifacts in a Package job to produce a war/ear file:
1st Create job called package> ‘In Post Build actions’ of your build job>Select Archive Artifacts- and provide, Files to archive as  **/*.war>save>build.

Step 2. Install required plugins:  Install copy artifact & deploy to container plugins.  Also install & configure tomcat and edit tomcat users file in conf folder of desired QA/Stage environment  to add a user with the role ‘manager-script’ in order to accept remote deployments.
Ex: <role rolename=”manager-script”/>
<user username=”admin” password=”tomcat” roles=”manager-gui, manager-script”/>

Step 3. Deploy the archived Artifact to defined environment: In the next job, named DeployToStage, pick up the archived war artifact and deploy it to a QA/Stage env.
a). 1st create a job called DeployToStage and then add Build Step-select copy artifacts from another project & provide the Project Name and Artifacts to Copy.
b). “Post-build Actions”. Select the option “Deploy war/ear to a container” from the “Add post-build action” dropdown button. Fill  war file, path and tomcat details>save>run.

Now, you can browse to your application in Staging environment via url;

In the next episode, we are going to see how can we achieve Continuous Deployment (CD) using Jenkins and a Configuration Management Tool called Chef.