In this article by Nikhil Pathania, the author of the book Learning Continuous Integration with Jenkins, we’ll discuss Continuous Deployment. Continuous Deployment is a very loosely understood term among the IT industry. Still more confusing are the differences between Continuous Deployment and Continuous Delivery. This article aims at defining Continuous Deployment along with examining its differences from Continuous Delivery.
(For more resources related to this topic, see here.)
What is Continuous Deployment?
“The process of continuously deploying production ready features into the production environment; or to the end-user, is termed as Continuous Deployment”.
Continuous Deployment in a holistic sense means the process of making production-ready features go live instantly without any intervention. This includes building features in an agile manner, integrating and testing them continuously, and deploying them to the production environment without any break.
On the other hand, Continuous Deployment in a literal sense means the task of deploying any given package continuously to any given environment. Therefore, the task of deploying packages to the testing server and production server conveys the literal meaning of Continuous Deployment.
The following illustration helps us in understanding the various terminologies that we discussed just now. In the following diagram, there are various steps that a software code goes through, from its inception till its utilization (development to production). Each step has a tool associated with it, and each one is part of some or the other methodology.
How Continuous Deployment is different from Continuous Delivery
First, the features are developed, then they go through a cycle or Continuous Integration or through testing of all kinds. Anything that passes the various tests is considered as a production-ready feature. These production-ready features are then labeled in Artifactory or are kept separately to segregate them from non-production ready features.
This is very similar to the manufacturing production line. The raw product goes through phases of modifications and testing. Finally, the finished product is packaged and stored in the warehouses. From the warehouses, depending on the orders, it gets shipped to various places. The product doesn’t get shipped immediately after it’s packaged. We can safely call this practice as Continuous Delivery. The following illustration depicts the Continuous Delivery life cycle:
On the other hand, a Continuous Deployment life cycle looks somewhat as shown in the following illustration. The deployment phase is immediate, without any break. The production-ready features are immediately deployed to production.
Who needs Continuous Deployment?
One might have the following questions rolling in their minds. How can I achieve Continuous Deployment in my organization? What would be the challenges? How much testing do I need to incorporate and automate? The list goes on.
Technical challenges are one thing. What’s more important is realizing the fact that do we really need it? Do we really need Continuous Deployment?
The answer is, not always and not in every case. From our definition of Continuous Deployment and our understanding from the previous topic, production ready features get deployed instantly to the production environment.
In many organizations, it’s the business that decides whether or not to make a feature live or when to make a feature live. Therefore, think of Continuous Deployment as an option, and not a compulsion.
On the other hand, Continuous Delivery; which means creating production ready features in a continuous way, should be the motto for any organization.
Continuous Deployment is easy to achieve in an organization that has just started. In other words, an organization that does not own a large code and has small infrastructure and less number of releases per day. On the other hand, it’s difficult for organizations with massive projects to move to Continuous Deployment. Nevertheless, organizations with large projects should first target Continuous Integration, then Continuous Delivery, and at last Continuous Deployment.
Frequent downtime of production environment with Continuous Deployment
Continuous Deployment, though a necessity in some organizations, may not be a piece of cake. There are a few practical challenges that may surface while performing frequent releases to the production server. Let’s see some of the hurdles.
Deployment to any application server or web server requires a downtime. The following activities take place during a downtime. I have listed some of the general tasks and they may vary from project to project.
- Bringing down the services
- Deploying the package
- Bringing up the services
- Performing sanity checks
The Jenkins job that performs the deployment in a production server may include all these steps. Nevertheless, running deployments every now and then on the production server may result in a frequent unavailability of the services. The solution to this problem is using a clustered production environment, as shown in the following illustration.
This is a very generic example wherein the web server is behind a reverse proxy server such as NGINX, which also performs load balancing. The web server is a cluster environment (it has many nodes running the same services) to make it highly available.
Usually, a clustered web application server will have a master-slave architecture, wherein a single node manager controls a few node agents. When deployment takes place on the web application server, the changes, restart activities, and sanity checks take place on each node, one at a time, thus resolving the downtime issues.
Summary
In this article, we covered an introduction to Continuous Deployment and how Continuous Deployment is different from Continuous Delivery. We also discussed the requirements of Continuous Deployment and the frequent downtime of a production environment with Continuous Deployment.
Resources for Article:
Further resources on this subject:
- Maven and Jenkins Plugin[article]
- Exploring Jenkins[article]
- Jenkins Continuous Integration[article]
