This is one of two PagerDuty posts on Continuous. Check out our second one: Continuous — Build, Break, and Fix Fast

Continuous Deployment vs. Continuous Delivery

There is a large gap between the understanding of modern processes and technologies, and actually doing something with them. In the DevOps movement, many of the core functions have met wide adoption, such as orchestration, release automation, and analytics. But what have not been as widely adopted are the end-to-end processes of continuous delivery and deployment, which is not a case of understanding — It is dictated by existing organizational elements and practicality. Are you ready for continuous delivery and deployment?

There is a deficit in the definitions of continuous delivery and continuous deployment. So before I dive deeper into the topic, I need to give my definition. Delivery means up to release, but not direct to production. There is still a gate, and someone has to hit the Go button. Deployment refers to what is put directly into production after all tests pass. The difference might seem trivial, but it isn’t. Deployment not only allows but also requires releases on a daily basis. It also implies a very robust reverting mechanism, which is heavily reliant on great alerting and log analysis.

The remainder of this post will cover continuous deployment (referred to from this point as CD).

CD has two dimensions that determine its practicality. The first is related directly to the application. The second is related to the environment in which the processes are going to be implemented.

The Application

What I am about to tell you are “fightin’ words.” It is not (yet) widely accepted that CD is dependant on your application type and architecture. However, you will find that the CD pipelines that already exist share a lot of similarities in the nature of their application. And the companies that are opportunistic about CD but have not yet implemented it are running into a wall.

The aspects of application architecture that will prevent CD are:

1. Low Transaction Volume: If your application does not have enough activity, there is not enough activity to learn from. Thus, the impact of any release will not be apparent in a short time frame. And its outcome will not be statistically accurate.
2. Low User Base: One of the benefits of CD is that you can release new functionality faster, and perhaps some functionality that is deemed high risk. This will have an impact on your user base, but the idea is that you will choose not to provide all releases to all users. If you do not have enough users, then you will be unable to produce releases for sub-segments of your user base.
3. Not Using Full-Stack Deployments/Architecture: If you are not deploying your application as the entire stack machine, OS, configuration, and code, problems will arise. The first is that it simply does not allow the developers to have enough autonomy with application releases, and this alone limits the ability to deploy to production without an IT hurdle. Next is that reliable releases need to be deployed on fresh infrastructure. This avoids issues with contamination, allows for predictability, and also supports the ability to release applications to sub-segments of the user base. With full-stack deployments, it is as easy as having the DNS control traffic to compartmentalized deployments. Using containers makes this much easier.
4. Not Leveraging Services Architecture/Microservices: I am not implying that your application needs to be a microservices application. But it does need to distinguish large application components as separate, mutually exclusive objects. This means that you can deploy individual components without impacting the entire application. The reason this is important is that in CD, if you are releasing the application in full, not only is it slow, the impact of any issue is many times worse — and your ability to respond will take much longer because you will have to re-deploy the entire application after a fix has been implemented, or re-deploy a previous version.

The Environment

Low transactions and low user base numbers are relative to your market and expectations from your users. It should be relatively clear to you whether you’ve satisfied these numbers or not. Beyond the attributes of your application, most organizations are attempting to implement CD in an existing delivery chain, which means there are existing processes and people to contend with. It’s possible to implement processes of CD without addressing the existing organization, but this usually leads to non-sustainable environments. Here are some key elements to consider:

1. It is not just developers: Although many of the processes are dictated by developers, they are not the only constituents. In CD pipelines, much more effort is spent on strategy versus execution. QA strategies are critical to ensure that there is proper test coverage before the releases occur. And a strong collaboration between IT will ensure that the alerting platforms, responsible for letting you know quickly if there is an issue with a release, are properly focused and set up. In some CD environments, developers have the ability to respond to issues directly.
2. Don’t forget about response: An unproportionate amount of time spent on planning for modern software delivery is spent on the forward motion of code. But success with future iterations is predicated on successful response to existing iterations. Organizations need to spend significant time on revert processes, and the system for responding to issues, which is both an organizational problem (who is on call), and a technology problem (taking as few steps as possible).

One approach to responding to both of these challenges is choosing to emulate what the startups are able to do: build the application with the CD process from day one. Because most organizations already have existing applications, this is not possible. The best way to do this is to build a new version of the application in parallel,  leveraging CD from the start. This will take time, but if your application was built with a services architecture, and a strong API layer for the backend, it should not be insurmountable.

Turning magic into reality is the real win. And many of the organizations who have successfully implemented CD have started with processes such as continuous integration first. They refined their approach, their tools, and their team structure in a way that gave them the confidence to move on to CD. They also focused on execution and sustainability, not just more releases direct to production.

Without jumping in on faith, the tool market will lead the way. And if your application lends itself to CD, and you are willing to do it right, you are ready for continuous deployment.

This is one of two PagerDuty posts on Continuous. Check out our second one: Continuous — Build, Break, and Fix Fast