5 Feature Flag Best Practices to Apply Today

Feature flags can help you change the way you release. They pave the way for decoupling deploy and release, lowering the number of environments, releasing when the work is ready, and so on. But feature flags aren't immune to code disasters. There are some feature flag best practices that new and veteran users alike should be aware of. Leveraging these best practices will help you get the most out of your feature flags—and prevent gnarly issues down the road. Let’s get started!

What are feature flags?

Before we delve deeper into the best practices for feature flags, let’s quickly refresh on what feature flags are. Feature flags—also termed feature toggles, feature switches, or feature flippers—are a way to enable or disable a product’s functionality without the need to change any code. They are used extensively by high-performing software engineering teams like Meta and eBay. 

Feature toggles are not something new; Flickr was using them in 2009. Thus, feature flags have helped amazing software engineering teams for easily more than a decade now. Feature flags not only help you test on production unlocking continuous delivery but also enable catching bugs in production before the code is served to 100% of your customers. Feature flags bring the philosophy of decoupling deploy and release (and realising that deployment is not a release) into practice. 

Feature flag best practices

There are so many ways to use feature flags. A super-slim feature flag can be as simple as an `if else` in your code. They can also be used for kill switches, A/B testing, phased rollouts, and more.

If your feature flags get more complex than simple booleans (or if your team is scaling up), opting into a full-on feature flag service of software like Flagsmith is a great investment. It helps you get ahead of code disasters and keeps feature flag management simple. Plus, then you get to see who made which flag changes when. (Flagsmith has a free plan for new users, and also has a self-hosted offering in addition to SaaS.)

The best practices for feature flags we are going to discuss next will be geared towards having a full-on feature flags software or service.

1. Plan ahead for feature flags

Similar to security, feature flags and code deployment should be planned early on when the task is written or ready to be developed. If the feature flag is layered in as an afterthought in the software development process it will not be as effective. How to slice the release and what feature flags will be used in each stage should be pre-planned rather than left for the last minute.

Let’s look at an example. Say you are leading a team for an e-commerce company that is aiming to replace the current payment gateway with Stripe for business reasons. One of the first things to plan will be how the Stripe code should be released. Another important aspect from a business perspective is how the phased rollout or canary release will work for both web and mobile apps.

As it is a payment gateway replacement, a big bang release with 100% of the customers switching to Stripe in one go would be pretty bad if things went south. If there is a bug, while it exists the company will not make any money. That’s too big of a risk to take, so these are the kinds of things where feature flags should be planned ahead when designing the implementation. For the same payment gateway example, we would recommend a Canary Release where Stripe is first rolled out internally, then to a small percentage of customers, and finally to the whole user base. Generally, it will be the product manager to make the call on what percentage of the customers get the new feature. These decisions are agreed while planning but it may change course when the code is in production behind a feature flag. So remember, plan ahead!

2. Name feature flags consistently and use tags efficiently

As Phil Karlton said, “There are only two hard things in Computer Science: cache invalidation and naming things.” Naming feature flags is not an easy task, and things can get convoluted quickly. The trick is to be consistent and have appropriate naming conventions in place for your feature flags. For instance, a feature flag that indicates if a feature is available or not must always end with `_enabled` like `fb_ads_enabled`.

The next important distinction to make here is the existence of “temporary” feature flags. These types of feature flags should have a way to be identified. One of the easiest ways to do it is to prepend the name with the word `temp`. Naming feature flags well helps save yourself and others in your organization a lot of headache and will always be a best practice for feature flags.

Flagsmith offers some super helpful features that make naming and identification easier. The first is the ability to add a description. Adding a clear and thorough description on the feature flag is an added bonus to having clear names. Similar to useful code comments, great descriptions act as a torch in the dark for your future self. 

Another helpful feature that Flagsmith has is tags for feature flags. These can make identifying different types of flags simple. For instance, there can be tags for platforms like the web, android, iOS. There can also be tags with names of your microservices if you and your team is using microservices. Tags really help you and your team organize feature flags in a better manner.

The list of best practices can go on for naming, the crux of the matter is to name your feature flags in a way where if you come back to it after 6 months you can easily recognize why the feature flag was created. This is where the power of having a well-defined naming convention makes that positive difference. Consequently, next up we will discuss pruning not-needed feature flags.

3. Remove feature flags that are not needed anymore

As mentioned above, there will be temporary feature flags that are generally used for releasing a new feature. These types of feature flags generally have a lifetime of weeks not months. For this class of feature flags, a best practice is to name them with a `temp` prefix or use a ‘temp’ tag so that they can be identified easily. The same can be said for feature flags created for experiments. There can be more permanent feature flags that are also not needed anymore. Pruning these feature flags also helps you and your team lessen the feature flag debt that can be accumulated in months and years.

For example, let’s go back to that Stripe release feature flag we were discussing earlier. Let’s say one fine Monday morning our new payment gateway Stripe is now getting 100% of the traffic without any bugs. We moved from 90% on Friday to 100% on Monday. That means in some days all the feature flags related to the Stripe release can be removed. This is also a good part of the deployment plan to have pre determined.

Another example that comes to mind is when we have feature flags that control traffic going to a microservice. We wrap these types of features in flags so that the critical path is not blocked. When we decommission microservices that are not used anymore, don’t forget to remove the related feature flags. You and your team should be vigilant about these and remove feature flags that are unnecessary. (Here's a little more on feature flags and microservice architectures.)

A periodic health check of the feature flags is also a best practice, and it helps to have it routinely scheduled. Flagsmith offers an easy way to do this with flag analytics. With flag analytics, you and your team can easily see how many times each feature flag has been evaluated in the past 24 hours or 30 days. That takes us to the next best practice for feature flags, keep the scope small.

4. Keep feature flags' scope optimal

Feature flags, like other things in code and technology, can be less helpful if used awkwardly. A good way to implement feature flags is to limit the scope of each feature flag. A good naming convention will also help in narrowing down the coverage of a feature flag. The main aspect to look at is to keep the range of the feature flag optimal, yes it has to be small but not too small.

For instance, let’s say you have an e-commerce website and you’re releasing a few new features at once; one that adds items to a wishlist, and another that alerts users on back-in-stock items. This would best be done using two feature flags; one for the wishlist, and another for the back-in-stock feature. This will keep the scope separated and small. If the same feature flag is used for both, the flag will cover too much. There will be overlap and you and your team will have a hard time figuring out what that particular flag does in the near future.

Yes, it pays to limit the scope of your feature flags, but this can swing too far as well. If we have 3 feature flags for the wishlist it will be overkill. For example, if there is one flag to add to a wishlist, another one to show the wishlist, and a final one to delete from the wishlist. This becomes too granular and too specific in scope, so it is much harder to maintain and contributes to feature flag debt. Subsequently, we will discuss how to use environments effectively.

5. Use environments effectively

Most software engineering teams have a staging and a production environment. Depending on the size of the organization and the structure of the tech teams, some have a QA (Quality Assurance) stage as well between staging and production. The best practice here is to create a feature flag on all the environments and test it along the way. If things don’t go as planned in production, the feature can be turned off from the interface by the click of a button. If all goes well the feature can be released as planned (see best practice #1).

Flagsmith by default provides two environments, development and production for each project you create. When you create a feature flag in one environment, it is created automatically in the other environment too. This makes it very easy to keep the feature flags in sync between environments. As a note of caution, always be extra careful even with feature flags in the production environment. Feature flags help us release software safely and if the configs are not applied properly it could lead to unwanted bugs and releasing a feature to unintended customers. Using these feature flag best practices will help you succeed with your flags.

Conclusion

Feature flags are a great technique that provides you and your software engineering team with unprecedented powers. But with great power comes great responsibility too, that's why adhering to these feature flag best practices will help to get the most out of them.

Happy feature flagging!

>>Sign up for free and use feature flags!

About the Author: Geshan Manandhar is a software engineer and blogger. Read more content on his personal blog.