How to Successfully Implement Feature Flags

• Share on Facebook
• Share on LinkedIn
• Share on X

So often there comes a time where features of an application need to exist in their intended environment in order to see how they function. It could be to test interoperability with existing features or entirely new portions of the application. In any case, using CI/CD to roll forward with the intent to roll back to a prior version can be risky. 

A less risky and intrusive approach is the use of feature flags. When implemented correctly, feature flags allow for functions of an application to exist in hiding. While not necessarily a production solution, it does allow for a deployment method by which these features can be nested and enabled. 

While other solutions exist for more complicated scenarios, learning how to successfully implement feature flags is popular for the testing and implementation of new software features. Continue reading to learn more about what feature flags are and when they should (or shouldn’t be used.)

What Are Feature Flags?

To sum it up, feature flags are a method used to toggle functions on and off depending on logic in the application that checks for an external configuration value. That configuration can exist in a number of places: 

• Configuration files deployed on the same resource.
• Environment variables set during deployment.
• A configuration file that exists in the cloud.

One aspect that makes this different, as well as powerful, is the fact that the logic that needs testing is already deployed to the server. It exists in a way that allows it to be fully deployed yet not interact with the existing application features. However, the additional logic does add a bit of technical debt.

Some technical debt is deemed acceptable when considering the benefit gained. Although usage of feature flags in this manner usually does not inject much extra work. After all, the new logic for the feature is already completed and deployed. Another release may replace the feature flag logic with the actual implementation after all testing and verification are completed.

Feature flags can create complications in the deployment pipeline and in other ways if not kept in check. These cases are good examples of when a 3rd party solution for helping implement features iteratively may be an option. Losing the ability as to how to successfully implement feature flags can provide for a management nightmare.

How Do Feature Flags Work?

When you think of feature flags, think of them as adding a conditional aspect to a new logic. This condition is checked against an external configuration value of some type. By adding this condition check, teams have opportunities to continue coding on one version in the codebase while keeping fine-grain control over enabling new features. 

These flags are also called feature toggles since they effectively toggle features on and off. Irrespective of the terminology used, It is important to note the difference in this type of toggle versus one that a user may modify in an application’s settings. Those are configuration or preference items that are meant to persist through the production application’s lifecycle.

When Should They Be Used?

Clearly, the initial reasoning for feature flags is to provide a means to turn aspects of the software on and off without the need to redeploy each time a new feature is released. One example that comes to mind is how QA can use these to ensure the experimental items are active in pre-production with the option of being enabled once deployed to production. 

By creating conditional logic that is environment-aware, DevOps techniques for CI/CD processes can ensure features are enabled when deployed to development or a QA environment. This would ensure the new code is always enabled for testing. 

When the same code is deployed to production, the opposite is true, and the feature may utilize a different condition to know when to be enabled for production. Doing this allows for less source code maintenance, cleaner branching techniques, and fewer deployments to multiple environments. 

The less time spent deploying code is also helpful in maintaining stability. Deployments inherently carry a level of risk with them. Even with the best automation for your CI/CD processes, there is always the possibility to create a negative user experience. Fewer deployments mean less opportunity for error. 

Another aspect of deployments is overwhelming users with new features. Rather than provide everything at once, it is sometimes better to take an iterative approach to changes. Implementing things slowly to allow them to be adopted by users often helps lessen negative experiences and guides them into using the newer features. 

Larger, monolith-style solutions may require a lot of extra work for even small features. Work in the form of packaging and deploying an entire application each time a new feature is enabled. Those that have used methods like microservices to separate different aspects of the application understand how this approach differs from a monolithic style of development. Using feature flags in this scenario would allow for fewer deployment cycles and enable their usage on your schedule.

When Shouldn’t They Be Used?

It is generally not acceptable practice to add logic that deals with permissions or security using feature flags. Nor would it be prudent to add something like this to control encrypting, decrypting, or storing data. Features related to security have too many implications to be taken lightly. There are always risks that may not be able to be accounted for in all environments. 

In the case of devices or otherwise offline systems, using feature flags that fall back on local configuration is one item to be wary of. If a mobile application is designed to enable features of itself by retrieving a configuration file from the internet, it makes sense that it would need an initial configuration that allows it to work offline. Because of these requirements on values that could potentially be circumvented, it makes this not a good candidate for a feature flag solution.

Cost is a factor, and not just a dollar amount. As discussed earlier, technical debt should be a consideration for those asking how to successfully implement feature flags. Since they require a bit of record-keeping to maintain manageability, things can get pretty confusing if that debt isn’t eventually paid off. Another way they can cost is application warmup. A check of a few feature flags may not create that much impact. Many features over multiple instances of an application can really add up to a slower performance.

Feature Flags in Action

We are going to look at a simple C# snippet to discuss the basics of a feature flag:

if (featureFlag) {
    // Run this code block if the featureFlag value is true
} else {
    // Run this code block if the featureFlag value is false
}

Looking at the code above, we can see that if the featureFlag variable of type “bit” is evaluated as true, that section of code will execute. In this manner, the feature flag’s logic is outside of the new code. 

Many languages offer libraries to help with feature flag usage. Microsoft provides an in-depth tutorial on their implementation of feature flag libraries for .Net Core applications. Stripped down to the simplest form, these libraries remove the need for multiple “if” statements. In conjunction with a tool like Azure App Configuration allows for easier management of your features.

Closing

In review, we hopefully have shed some light on what feature flags are as they apply to software development. You can use this methodology to provide a means for A/B testing, separately paid from free content, or to help wrangle a tough-to-manage codebase. Although not every case is a good candidate, it is vital to know how to successfully implement feature flags so all options are available to the team. In most cases, you can start with simple methods to get feature flags in your application. However, being aware of tooling and other products that are designed to help with the implementation is also helpful.

Omer Mishania

DevOps Engineer at MeteorOps, is obsessed with building elegant and simple DevOps solutions. Experienced with building platforms for engineering teams. Focused on finding ways to make provisioning, deployment, orchestration, monitoring, and much more, accessible for development teams.