Outside of an educational setting, all software is built to be used by people (or perhaps in rare cases, non-human animals). The final stage in this process of getting software in front of its users has many names. Two common ones: Deploy & Release.

Are these terms synonyms?

This is actually a complicated question, because both terms have multiple meanings, which in some cases overlap, and in other cases have practically nothing to do with each other.

For example, as a noun, a “software release” is usually thought of as a specific set, or build of software, often identified by a version number. By extension, creating this “release” can be thought of as “releasing the software.”

Similarly, a “software deployment” is often thought of as version (or “release”) of software, as installed in a specific environment.

But I want to focus on a slightly different aspect of these two words, one which is often overlooked, particularly as it relates to features of software, as opposed to an entire software system. I’ll start by making a claim that may seem counter-intuitive to many, then try to justify it.

It is possible to deploy a feature without releasing it.

As a sort of logical extension to the idea that delivery comes before, and is disinct from deployment, deployment may come before, and can be distinct from a release. In particular, this happens any time you deploy a feature that is disabled by a feature flag.

So what?

This can have profound implications in certain situations. Two of the common complaints I hear against continuous deployment are directly addressed by this observation:

Reason 3: Our end users need to be informed of all changes Reason 4: We’re working on a big feature that’s not ready to deploy yet

By decoupling release from deployment, it’s possible to address both of these concerns, while still doing continuous deployment.

Are you worried about the complexity of feature flags? Don’t be. Getting started is easy, and requires no new frameworks or technology.