What Is Continuous Deployment?

Continuous Deployment Introduction

Navigating to Google and typing in “DevOps Continuous…” returns more terms than can fit on the search page. Continuous Integration, Continuous Delivery, Continuous Deployment, Continuous Monitoring…. and on and on. Frankly, it's gotten a bit out of hand. 

Continuous anything has become the new industry buzzword. Unfortunately, this makes it difficult to define and study what these terms mean; especially when the terms seem identical. Example: Continuous Delivery vs. Continuous Deployment. What in the world is the difference between these two? Is the difference only semantics? Turns out there’s a big difference between deploy and deliver. A Continuous Deployment process and deployments pipelines are a part of a Continuous Delivery process, but each strives to reach different objectives. 

In this article, we’re going to compare and contrast the methodologies of Continuous Deployment and Continuous Delivery. We’re also going to deep dive into Continuous Deployment to make sure you understand how it could benefit your development teams. 

Continuous Deployment vs. Continuous Delivery

As the name suggests, Continuous Deployment focuses on the installation and distribution of features and updates. Generally, after a Continuous Integration process, an application will travel through several lower-level environments where a QA team might run regression tests, unit tests, or utilize testing automation to make sure the code is of high quality. The application, after going through lower-level environments, is pushed through to the production environment. We refer to the automation of all these stages as a Continuous Deployment pipeline. The goal is to reduce the amount of human intervention needed by using various triggers and repeatable steps. 

On the other hand, Continuous Delivery includes all the automation steps of Continuous Deployment, but with the added automation of security, compliance, and verification to decrease the risk associated with each deployment. So, a Continuous Delivery pipeline (CD pipeline) should include governance approval steps, it should include safer deployment strategies like canary and blue-green deployment, and should include post-deployment verification to make sure everything is working optimally for end users. 

For more information on the differences between Continuous Deployment and Continuous Delivery, check out the linked blog post.

Continuous Deployment Principles

Part 1: Artifacts

Continuous Deployment starts once we package new code into an artifact. There are a couple of approaches to take once the CI process is complete. On one hand, the artifact can be stored in a repo until said company reaches their normal deployment cadence. There could be various reasons for the delay: a deployment culture that only promotes weekly deployments, a heavily regulated industry with more compliance rules, a company that doesn’t have many lower level environments to deploy into. Either way, a company that chooses to delay their initial deployment process can still practice Continuous Deployment later in the cycle. The other option is to immediately deploy a new code change into a dev-integration and/or quality assurance environment to start integration testing. Since these lower-level environments pose low risk, this is often low hanging fruit to begin integrating a Continuous Deployment mindset. 

Part 2: Automating the Deployment

The next step is to look at automating the deployments to and between lower-level environments. This is where it's important to start utilizing pipelines to standardize deployments. In an ideal world where software development produces several deployable artifacts each day, unstandardized practices can quickly become bottlenecks. The name of the game is to create a pipeline that is easily understood by other developers, is repeatable for every deployment, and is scalable to other teams. A pitfall companies run into is creating unique deployment pipelines for each environment and each team. While at first glance it may make sense to create hyper specific deployment strategies, it eventually becomes a maintenance nightmare. It should take no more than a few minutes to deploy artifacts to testing, and it should require minimal maintenance to keep those pipelines operational. 

Part 3: Production

The last major component of Continuous Deployment is the production deployment itself. The minimal gold standard for production is to perform a rolling deployment. This type of deployment replaces old application nodes in an incremental level, typically one by one, until all the nodes are the new version. This is a safe way to switch to a new version while using validation tools to make sure the deployment was successful. Other potential deployment methods include blue-green deployments and canary deployments. It's important to note that a standard deployment strategy should be used across the company’s applications to reduce the complexity of scaling.

Continuous Deployment In Practice

It's one thing to discuss Continuous Deployment. It's another to implement the practices in an organization. Here are some examples of Harness customers who are making strides towards a true Continuous Deployment process.

Choice Hotels spent a large amount of resources creating automation, but didn’t have a good way to streamline all the automation into a continuous process. This meant deployments could only occur at 10pm once a week and took a total of 12 hours. Harness helped Choice utilize automation to bring the deployment effort down to 2 hours and let the team deploy at any time during the week. To quote the customer: “Harness helps us capitalize on the investments we’ve made in automation tools by streamlining everything into a single pipeline.”

Zepto was tired of subjecting itself to slow and unreliable software deployments. “We had to use our most costly business resources to deploy software and maintain scripts,” said Trevor Wistaff, CTO. This meant that Zepto was only able to deploy twice a week. Once their team adopted Harness, deployment time reduced from 20 minutes to less than 1 minute. This increase in speed and reliability lets Zepto deploy new features 3 times a day.

Final Thoughts

As an organization scales, different stakeholders will want to automate engineering processes. However, it doesn’t matter how much automation there is if the final release to customers is slow. Continuous Deployment strategies should relieve this pressure and allow companies to get new code and bug fixes to customers faster. 

If you’re still worried about how you would implement this at your organization, take a look at Harness. Our CD solution can abstract away the complexity of Continuous Deployment so you can focus on building great software. 

Looking to learn more on CD? We’d love to point you to our eBook, Pipeline Patterns. It’s an invaluable resource that will help you optimize your pipelines for improved time to production & less failed deployments, pick the best pipeline for your needs, and more.