Deploying vs releasing: What you should know to prevent outages

Many organizations are optimizing their software delivery for CI/CD to achieve fast, frequent feature releases and stay competitive. Yet even as companies optimize for continuous deployment, many still experience outages in production. Why?

The reason is that deployment and release are two separate technical procedures. You can be regularly deploying to production but still be doing rolling updates as part of your release process. That means big, risky releases that result in issues.

It doesn’t have to be this way. There are better ways than “big-bang” releases, where the best you can do is hope the release is successful. In this article, you’ll learn how you can rethink your release process to move beyond big-bang releases and ship features to customers safely and more frequently.

Deploying vs releasing

A lot of IT professionals and vendors confuse the words “deploy” and “release.” There is a big difference. At CircleCI, we believe that treating release as an independent step in your shipping process is crucial to delivering a great customer experience. In this post, we’ll explain the difference between deploying and releasing.

A deploy, or deployment, includes all the technical activities required to make a software system or feature available for use. Think of a fresh Docker container running in a pod on a Kubernetes cluster. The piece of software passed all checks and tests in your CI/CD pipeline and is ready to receive traffic from production users, but it is not yet receiving any.

This part of the process is just to make sure that the new version is healthy and running smoothly. It takes care of all the technical checks and balances, without any of the risk incurred by serving actual production traffic. In this sense, deploying a piece of software is a mundane and risk-free activity.

A release comes after a deployment and includes all the activities that are needed to move part of, or all, production traffic to the new version. All the risks and things that could go wrong–downtime, lost revenue, angry managers and customers–are related to the release, not the deploy. That makes releasing a piece of software exciting but risky. It’s an activity that deserves more attention.

Risk-free releases with release orchestration

IT professionals know the feeling when you push that all-defining release button, and the new version starts to serve production traffic. It’s a nail-biting, nerve-wracking moment when the release engineer redirects all production traffic to the new version. The reason that happens is that you might have continuous deployment, but you are still doing a rolling update, or big-bang release, to production. So, what’s the alternative?

Target a small segment of users with canary releases

A good methodology to prevent “big bang” is canary releasing–that is, trickling in a small sub-segment of user traffic. Traffic can be incrementally directed at the new version, slowly increasing the load, while you monitor for any performance issues, transactional errors, or code bugs. By starting out with a small group of users (either a percentage of all users or a specific segment, such as all logged-out users), you can validate your changes in production without any of the risk of releasing to all users at once. This safeguards the quality of your code and minimizes the business impact should a release fail.

The smaller your releases, the better, faster, and more flexible each release is. It is easier to know what goes wrong if there are only a few changes in each release, making it easier to fix. Moving to smaller and smaller atomic releases is a vital part of a more mature release approach.

Automate your release strategy with release policies

Canary releasing is the risk-free, rollback-friendly alternative to big-bang releases. But manually babysitting each canary release, making arbitrary decisions that vary from release to release, still doesn’t provide you with a robust, reliable approach.

Instead, it makes sense to codify these decisions into release policies that control the conditions around each release and execute each canary release using those policies in an automated, hands-off way. That way, you know your releases will follow the exact same release process, using the same parameters to increase the rollout or rollback of a failed release.

A release orchestration engine uses policies you create to make decisions for you, so you can comfortably make more use of your time, knowing that the new version will not have a negative impact on your customers’ experience—even on a Friday night.