Feature Flag Best Practices: Change Management in Production

The following is a guest blog post written by Michiel Mulders.

Feature flags offer a great alternative for rolling out features to a select group of users in your user base. They also support a gradual rollout of features instead of releasing a group of features altogether. This allows your users to gradually learn about new features and functionality.

But how do feature flags help with change management?

This article discusses how feature flags help with change management and introduces seven best practices to consider when using feature flags.

Many product managers struggle with managing releases—in particular, with grouping features and avoiding code conflicts. Feature flags help you manage releases because they allow for gradually rolling out new features. Code conflicts can be minimized or even completely reduced as developers can easily enable or disable certain features.

In addition, when you release a bunch of features to your users at once, this can seem overwhelming. Users suddenly see many new features, or that the behavior of an existing functionality has completely changed. This can be confusing for new and experienced users alike. As always, change is hard, and you should reduce the amount of change you expose to your users.

Therefore, consider using feature flags to gradually roll out new features to your users. A gradual rollout plan will reduce the number of changes, so users can slowly adapt to each new feature. In other words, change shouldn’t be hard—change should be easy.

Lastly, feature flags help with change management as developers get involved in the release process. Feature flags jump onto the DevOps movement, where developers have more control over the production system through the use of feature flags. Traditionally, the release process is heavily regulated by the release team, where the dev team hands over the code for deployment. Feature flags allow developers to temporarily disable their feature and merge the code to the release branch while the feature isn’t completed yet. This is a great approach for avoiding code conflicts.

Next, let’s explore some best practices for using feature flags for change management.

Here are seven feature flag best practices related to change management.

A canary launch allows you to roll out one or multiple features to a small group of users instead of your complete user base. The goal of a canary launch is to gauge interest for one or multiple new features. A canary launch tries to find answers for the following questions:

• How do users use the new feature?

• Are users happy with the new feature?

• Can we make more profit launching this feature to the full user base?

• How stable is the new feature? Does it contain any bugs?

A canary launch is ideal for answering the above questions. And if a feature isn’t good, you can simply roll it back using your feature flag.

Without the use of feature flags, a canary launch is still possible but becomes more complex to manage. From a change management perspective, changes should be easy, efficient, and quick. You don’t want to spend a lot of time reverting code if a particular feature doesn’t satisfy the users’ needs.This means a feature flag removes the need for hotfixes or redeployments of the code when a feature needs to be removed. You can just disable the feature from your dashboard without redeployment or a hotfix being needed.

If you can use a feature flag to quickly enable or disable a new feature, why not use it as a kill switch? A feature flag can be explained as a simple if-statement that enables or disables a piece of logic (also referred to as a feature).

Therefore, we can “abuse” a feature flag as a kill switch to quickly disable a whole feature in a running production system without having to redeploy a new release. You can program a feature flag that can be controlled via a remote call, such as an API call, to kill a certain feature in real time in your production environment. 

This is extremely useful for when you detect a critical bug in a new release and you want to quickly disable the feature for all users. In this case, you can use a feature flag as a kill switch.

Feature flags tend to make code complex as they introduce new code paths. When you have multiple active feature flags, they could interfere or cause conflicts. In other words, managing changes becomes much harder as features interfere and team members struggle to understand the different changes.

Change management should be easy. Therefore, it’s important to manage your feature flags. For example, define a policy that determines which feature flags act as short-term flags for A/B testing, performance testing, or as a temporary release switch. You might also define long-term flags, such as a kill switch, circuit breaker, or a flag for controlling premium features.

A feature flag nomenclature can help you quickly identify the use and purpose of a feature flag. Furthermore, a team member immediately knows which change project a particular feature belongs to. Imagine a piece of software that has the following feature flags defined:

• Enable_feature_001

• Enable_feature_002

• Temp_release_feature_003

These names don’t communicate any actionable information about the feature flag’s purpose, use, or longevity. Instead, make it a priority to define meaningful names for feature flags so you can quickly determine if a feature flag is still needed and what its purpose is.

When defining a name for a feature flag, make sure to include the following information:

• The feature’s name

• The feature’s longevity—whether short or long term

• The date it was created

You can also keep track of the feature’s purpose  and whether the feature flag interferes with other feature flags.

Set up a recurring calendar event that forces you to evaluate your active feature flags. For example, every two weeks, look for outdated feature flags from past releases or A/B testing experiments. When you dedicate time to cleaning up old feature flags, you’ll be less likely to run into feature flag conflicts. In other words, try to keep your feature flag management clean and simple. A clean feature flag overview will help you to better control your change management.

A feature flag management tool helps you easily manage all of your feature flags from a central interface. This simplifies change management as you can quickly enable or disable features from a single interface. Further, a feature flag solution such as CloudBees allows you to use an SDK that offers many prebuilt building blocks for quickly adding feature flag solutions to your application. 

For example, instead of writing your own kill switch code, CloudBees’ feature flag solution comes with a built-in kill switch solution. Want to learn more about CloudBees’ feature flag solution? Visit CloudBees’ product page.

Feature flags support change management through phased releases to minimize the risk of new features. Changes should be small. Therefore, you can use feature flags to adopt a phased approach to releasing features. For example, the following phases could apply.

1. Canary release

2. Beta release

3. Phased roll-out

Many more change management-embracing combinations are possible to allow you to release features to your users. The idea is to minimize the impact of the change to your users and let them gradually adopt new features.

Feature flags are a great solution for giving developers more control over the release process, but they also change the way developers work. Instead of releasing a group of features, your team can switch to gradually rolling out new features to reduce the impact of a change. This also means that developers can push code into production while disabling the feature through feature flags. 

In addition, the dev and release teams can work closely together, because they’re both responsible for deployments and the activation of features. 

Want to learn more about feature flags? Check out CloudBees Feature Management.

Michiel Mulders is a passionate blockchain developer who loves writing technical content. Besides that, he loves learning about marketing, UX psychology, and entrepreneurship. When he's not writing, he's probably enjoying a Belgian beer!