Feature Flags Best Practices: The Complete Guide

Feature flags—also known as feature toggles, feature switches, or feature flippers—can transform the way you work. They pave the way for decoupling deploy and release, letting you reduce the number of environments you work in and release code when you’re ready, rather than waiting on others for a large-scale, coordinated release. High-level benefits include improved developer morale and team productivity.

TL;DR? Feature flags give you the agility to build better products, faster. 

Before we delve too far into the benefits of feature flags, it’s important to note that they aren't immune to code disasters. To avoid the potential pitfalls, there are some feature flags best practices that new and veteran users alike should keep in mind. Leveraging these will help you get the most out of your feature flags—and prevent hairy situations down the road.

But first: What are feature flags?

Who doesn’t love a quick refresher? Better than a quick pop quiz! Before we get into some feature flag best practices, a reminder of what feature flags are. Feature flags are a way to enable or disable a product’s functionality without having to change any code. 

They are used extensively by high-performing software engineering teams at companies like Meta and eBay. And they aren’t new. Flickr was using feature toggles back in 2009— in fact, they’ve helped software engineering teams build great products for more than a decade now. Feature flags not only help you test in production, unlocking continuous delivery, but also help you catch bugs in production via canary deployments. 

How to implement feature flags

When it comes to how to implement feature flags, it’s best to start small. Consider implementing feature flags for one team or a shovel-ready use case before introducing them to a wider swathe of the company. That way, you can incorporate learnings specific to your company's needs and optimise as you go.

Before you start, you’ll need to decide if you’re going to build an in-house solution or find a feature flag provider that fits your needs. Many companies choose to build their own solution at first, only to realise later on that this can quickly spin out of control—as feature flag adoption grows, so, too, does the complexity when managing this on your own. Some common issues with homegrown solutions are: 

• Spending a lot of time manually adjusting flags for product owners or the business 
• Lack of transparency (who changed what, when)
• No way to control access based on user

Feature flags as a service providers like Flagsmith allow you to sidestep these issues and scale usage with ease. 

How to use feature flags

Feature flags are a powerful tool—when used right.  Using feature flags will likely mean a new way of working for your team. Continuous deployment and testing in production, though starting to be regarded as best practice, can take some getting used to. Setting up the proper workflows and documentation for how to use feature flags will help drive adoption and set your team up for success.

Feature flags best practices

There are many ways to use feature flags. These range from super lightweight booleans to more complicated string and integer-based options. If you’re treading into more complicated territory, applying some feature flags best practices (otherwise known as feature toggle best practices or feature flagging best practices) is important. Especially if you have a large number of flags and multiple team members working together on a project. Things can get complicated quickly!

The following feature flag best practices are geared towards anyone currently using—or considering—a feature flag provider. 

1. Plan ahead

Feature flag deployment should be planned early on in the software development process. If they're simply layered in as an afterthought, they won’t be as effective. How to slice the release and which feature flags will be used in each stage should be pre-planned rather than left for the last minute.

Let’s look at a feature flag example. Say you’re leading a team at an e-commerce company that’s planning on replacing the current payment gateway with Stripe. As you start to plan out how the Stripe code will be released, you also need to think about how this will work for users across web and mobile. 

For an e-commerce company, the payment gateway is mission-critical, so a big bang release that moves 100% of customers to Stripe in one go is too risky.  If there’s a bug, the company risks losing money while it’s being fixed (not to mention eroding customer trust and goodwill). This is where feature flags come into play—and make things a whole lot smoother and less stressful. A canary release,  where Stripe is first rolled out internally, then to a small percentage of customers, and finally to the whole user base, would be the best course of action here and should be planned from the start.

2. Limit the scope of your feature flags

While multitasking is great when it comes to checking items off your weekly to-do list, this same ethos doesn’t necessarily apply to feature flags.

Let’s stick with the e-commerce example. Say you’re releasing a few new features at once, centring around two outcomes: adding items to a wishlist and alerting users when items are back in stock. Feature flag best practice would be to use two flags here: 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 use cases, the flag will cover too much. There will be awkward overlap, and you and your team will have a hard time figuring out what this particular flag does (naming conventions will help with this, too).

Whilst it pays to limit the scope of your feature flags, this can swing too far in the other direction, too. For example, if you used three flags for the wishlist feature (one flag to add to a wishlist, another one to show the wishlist, and a final one to delete from the wishlist),  this will become far too granular and specific and leads to unnecessary flag debt.

2. Introduce consistent feature flag naming conventions & 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 can easily become convoluted. The trick is to be consistent and have appropriate naming conventions in place.

The list of best practices for naming your flags can go on and on, but the crux of the matter is: name your feature flags in a way that’s so clear, that if you come back after 6 months, it’s immediately apparent why the feature flag was created. This is where the power of having a well-defined naming convention comes in (it also removes the burden of decision every time you introduce a new flag!).

Create a naming convention

Ideally, your feature names should communicate what the feature is and what it does, as this will allow other developers to get the information they need right away. In Flagsmith, the name is referred to as the Feature ID. You have to choose an ID when you first create a feature, and you can’t rename a Feature ID, as you use that Feature ID in your code. Choose your convention upfront and stick to it!

Use clear and thorough descriptions

Just like adding clear comments in code makes for better code, adding clear descriptions to your features makes them better. Like code comments, these should be concise descriptions of what the feature is intended to do and why. In Flagsmith, this is the Description. It’s optional, but we advise that you use it consistently. The description can be changed at any time.

Add tags to your flags

Not all feature flagging software provides the ability to add tags to your flags, but it’s super useful. With Flagsmith, once you’ve created a feature, you can edit it and add one or multiple tags. These are optional and can be edited at any time. Tags help you quickly filter features, and since they can be different colours, they allow you to identify the purpose of different features at a glance.

You can use tags to classify features in different ways. Some teams classify their features based on the service that they are part of. Others group them around the teams that are working on them. Use a taxonomy that fits your team and product. You can also classify them based on flag role; some flags might be used to roll out new features and hence have a limited life span (more on that below). Others might be used to control which features are shown to users in different pricing tiers.

‍

3. Remove old feature flags

Feature flags that are associated with releasing a new feature will generally be temporary and should be deleted once they've served their purpose. These types of feature flags generally have a lifetime of weeks, not months. For this class of feature flags, a best practice is to use a “temp” prefix or tag so that they can be easily identified. The same can be said for feature flags created for experiments. Having old, unused features makes managing your flags more difficult and can lead to confusion or even conflicts. Pruning doesn’t only need to happen in your garden—trimming unused/expired feature flags will help you and your team lessen the feature flag debt that can accumulate over months and years. 

Let’s go back to that Stripe release we were discussing earlier. Stripe is now getting 100% of the traffic without any bugs.  You moved from directing 90% of payment gateway traffic to Stripe on Monday to 100% on Wednesday. That means that someday soon, all the feature flags related to this release can be removed. This is also something that should be pre-determined and included in the deployment plan.

Another example is when you have feature flags that control traffic going to a microservice. These types of features are wrapped in flags so that the critical path is not blocked. When the microservices are decommissioned, don’t forget to remove the related feature flags.

Scheduling periodic health checks is also a good idea. Flagsmith offers an easy way for you to do this with built-in flag analytics. This lets you and your team easily see the last time a feature was evaluated within your code, so you can quickly see which flags can be removed.

4. Use feature flag projects and environments effectively

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

Flagsmith, by default, provides two environments, development and production for each project you create. When you create a feature flag in one environment, it’s automatically created in the other environment, too. This makes it very easy to keep feature flags in sync between environments. 

You can add as many projects and environments as you like, but we recommend keeping a rule in place so everyone understands when to create a new project or environment.

We recommend using a new project for a distinct application, or when a different team works on a set of features, so that you can keep things from getting too complicated. For example, you would set up one project for front-end and another one for back-end, or a project for your mobile application and a project for your web application. These would all live in the same environment, though. Projects share flags within their environments, so use this to guide your taxonomy.

5.  Set up access controls

The last thing you want is for someone to accidentally switch on a faulty feature for your entire user base. This is where access controls come in handy. These should be used to give individuals different levels of control and restrict usage based on need. Just like with other software permissions in your business, the best practice here is to only give users the level of access necessary for them to do their jobs. 

Flagsmith’s Scale-Up and Enterprise plans offer role-based access controls that allow an organisation to manage access for users at a detailed level. Users can be categorised into groups and permissions can be managed at the group level. Users are given roles at the organisation level, and controls for users or groups of users can be further managed at the project and environment level. 

‍

6. Create and maintain audit logs for your feature flags

An important feature flagging best practice is to keep a log that tracks any features that are created, changed, or deleted as well as who took those actions. This is especially important if you have a large number of developers working in different teams. Having this information can save a lot of time and confusion in knowing what has been done, when, and by whom. For regulated industries, like banking, audit logs are often also an important part of compliance.

Keeping a log is important, but also an extra step of work likely to be missed from time to time. Built-in audit logs that automatically track every action taken on flags, identities, and segments can be a big help here. 

‍

Final thoughts

There is no one way to manage feature flags—the course you chart will depend on your organisational needs—however, these best practices should save you a lot of time when managing your feature flag implementation. Time you can instead spend building great products and testing features that delight your users!

Some recommendations

• If you’re curious about what it looks like to switch from a homegrown feature flag solution to feature flag software, check out our interview with Fabian Gübeli, full-stack engineer at Vontobel. 
• We've put together a free (ungated) interactive demo that lets you click through our platform and features, so you can get an idea of our capabilities on your own.
• Sign-up for free and start using feature flags today!

How-to guides 

Check out these feature flag how-to guides if you’re ready to dive in now.

• Angular feature flags
• Python feature flags
• Java feature flags
• Ruby feature flags
• JavaScript feature flags
• Flutter feature flags
• NodeJS feature flags
• Spring Boot feature flags
• PHP feature flags
• Golang feature flags
• Kotlin/Android feature flags
• React Native Remote Config
• Swift feature flags
• .Net feature flags

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