Click to learn more about author Dave Karow

Recently a very important question within the DevOps world was asked on Twitter. The question posed was whether or not everyone knew that deployment frequency can be decoupled from feature release frequency. Shockingly, the replies and retweets showed that for many, the answer was no.

The concept of decoupling deployment from release is a key thing for any DevOps team to be aware of, and it is important to understand how feature flags can make that possible.

Before we delve in, let’s start by looking at the definitions. Deploy is pushing your code to some part of your infrastructure and release is exposing code to execution. The ability to decouple deploy from release means that you are able to push code to anywhere without exposing the code, and therefore, without impacting your users. This then allows you to gradually release the new feature to assist in internal testing, dogfooding, and progressive rollouts. But what is most impressive is that, if done correctly, you can compare the health of system metrics and user behavior between the users who have access to the new feature against the users who do not yet have access and thus learn much sooner if there are issues.

Feature flags are what make the decoupling within a feature release possible. A feature flag, or feature toggle, is implemented as a function call that controls access to a particular code path. Unlike traditional compile-time flags, command-line flags, or configuration file entries, feature flags operate on a user-by-user basis (not per server image) and are remotely controlled from outside the application, which means they can be changed at any time without pushing new code.

Think of a feature flag as a volume dial that can be turned up or down at any time. Actually, it’s more powerful than that because the rules they implement can go beyond percentages to include any known attributes of the users. You could start by rolling out a particular feature to all testers, then 50 percent of employees, and then 5 percent of your free tier, etc…

Getting Code to Production Sooner

There are many reasons to want to decouple deployment from release, but there are two primary ones. The first is to prevent code that’s still being built out from being exposed to users before you’re ready to have it released. This is particularly important if your DevOps team utilizes trunk-based development. Under trunk-based development, all code is committed to master at least once every day. Without decoupling, all work in process code would go live the next time a deploy happens.

The second reason is to enable safe testing in production. Being able to safely test in production is important to any DevOps team, but the common worry is that you’ll have a large blast radius among your users if there are any issues. Decoupling allows you to gradually release the new feature while checking the health of system and user behavior metrics at each step along the way.

The overall idea when decoupling with feature flags is to start small. Release the new feature to a minimal low-risk demographic of your users and then gradually increase it to a larger high-risk demographic. If issues arise, you can instantly dial back the exposure of the release, keeping it within your internal teams so they can debug as needed. All this is doable by decoupling deployment from release, as it allows you to control the exposure of the feature without a rollback or roll-forward. If you meet with any issues, you are able to avoid re-deploying the prior version or having to deal with a rush build, test, and deployment of a patch, since you can just un-release the feature from the demographic of users that you exposed it to.