So what exactly are feature flags? Why do we need them for software development?

Learning outcomes of the article

By the end of this article, you will be able to understand what feature flags are, why feature flags are important within the development process, why it is important to separate the deployment and release processes for risk mitigation, why teams may choose to use feature flags, and where & when to use feature flags (use case scenarios).

However, before we delve deeper into feature flags, it’s a good idea to start with a general understanding of the general development process and how feature flags are related to the general process.

The development process, release & deployment

Manager: “Have you released the new version of the dashboard?”

Front-end Developer: “I’ve deployed the new dashboard to production.”

Anyone working in the IT industry will probably hear the terms, “deployment” and “release” being used interchangeably. It is easy to get confused about the exact differences between the two terms as there are no standardized or universal definitions behind each of these terms.

On top of this, many firms today still seem to understand the shipping process as a “deploy = release” practice. This article will describe the risk mitigation technique and reasons behind separating “deploy” and “release” as distinct entities during the software shipping process.

By separating release from deployment, an ideal development follows a build→deploy→release process. The “release” is not decoupled from the “deployment”. This is where feature flags enter the picture. Build→deploy→feature flag→ release.

To assist your understanding, here are the respective “updated” definitions of deployment and release.

deploy (verb): When a version of the software is installed onto a target location (app store, server, mobile application) that is not necessarily targeting customers or real users. As you can also deploy versions intended for development, the version that is being deployed does not have to be the version intended for the final release. (“A software developer deploys version 1.5 to the development zone.”)

Again, it’s important to note that deployment does not need to release the deployment version to real users.

release or rollout (verb): The act of making a feature release/delivering to customers and has an impact on real end-users. (“We’re going to release 1.5 to production tomorrow.”)

The advantages of decoupling “Deployment” from “Release” & incorporating feature flags in between the two decoupled steps for added control

For better understanding, let’s use a company creating mobile apps as our example, and the problems they can encounter when they deploy and release functions are coupled together without a feature flag.

1. When a problem with a feature within the app occurs, developers will have to go into the process of creating a new version and deploying the new version of the app after the faulty feature is fixed.
2. Once a new version has been deployed, users will have to go through the burden of updating their app version from the App store (burdensome + lead time to redeploy).

Perhaps the most significant impact would be that, in the meantime, users will have to experience the faulty apps for time being while the new version is being redeployed (significantly impacting and decreasing their user experience) and they will also have to go back to the app store to re-download the updated app.

However, once these two functions are decoupled and feature flags are used as the added control in between these two functions.

• It is possible to immediately return back to the original state of things with one flick of a button, switch, toggle and rollback a feature release.
• Overall, creating a better way to better manage consumer experiences.

Rolling back without feature flags in place

When features are released to users and there is no Plan B = feature flags

There is a high possibility that your team is going to ship something broken. This means that you need to rollback. A rollback is where you get the previous, non-faulty state back on production. In order to re-release the previous version, the rollback can be broken down into a deploy and release process.

However, redeploying or rolling back is a highly stressful situation for developers because

• The deploy and release process needs to be executed ASAP under time pressure
• You may be releasing the new version into a different environment — things may have changed during (or been changed by) the failed release.

Who/What Teams use Feature Flags?

All technology teams understand the importance of continuous integration (CI) and continuous deployment (CD), otherwise abbreviated as CI/CD. When given the tools to make sure that code is being delivered faster, you will achieve an overall increase in your customers’ satisfaction and the quality of the product.

Feature flags are one example of a tool that helps companies that aim for CI/CD. For companies that are aiming for CI/CD, it is hard to decouple release from deployment, creating a high risk for companies that release features quickly as some of the features may be faulty or may not have the intended results.

Catch two birds with one stone. “Release new features quickly and safely.”

So, all in all, is it possible for companies that aim for CI/CD to release quickly and safely? Yes, this is possible when you have added the control functionality of feature flags.

Following the build-deploy-release process that many developers undertake, although these tools were initially coined “feature flags”, the more precise term would be “release flags”. Many firms aim for continuous deployment with fast releases of new features in order to stay competitive and optimize their software for end-users. However, without having a separate toggle that allows you to control the actual release before deployment, you will end up with lost revenue, lost consumers, and angry managers.

From a traditional setting or in a world where feature flags do not exist, as soon as you deploy your code into production, the relevant features become visible to users. This moment of deployment is the most stressful stage for developers. This is because we often encounter situations where unexpected problems arise from untested, or even tested situations. With feature flags, such worries essentially disappear.

Find out how you can flag your deployment worries away with Hackle’s easy-to-use feature flags: www.hackle.io