Feature flags can give your team the ability to release faster and more confidently. However, like so many things in software development, the added stress of maintaining feature flags can overwhelm teams and stop them from exercising best practices.
The best way to make sure you effectively and consistently manage your feature flags is to make sure they meet their intended definition of done. Once a flag has served its purpose, you should intentionally deprecate it. Whether you are using the flag to test in production with your internal teammates, run an experiment, or serve as a kill switch, you should know the criteria to meet its definition of done. Because different flags have different sunsetting timelines depending on their purpose, let’s go through each scenario and discuss when you would want to deprecate each one.
The most common challenge I see teams facing with feature flags is that they have too many feature flags
Pete Hodgson, Software Delivery Consultant
Using a Feature Flag to Test in Production
Testing in production is the only way to know your features are working in production right now. When you use feature flags to test in production, you are adding a layer of risk mitigation to your software delivery process and increasing your team’s confidence that your feature works in the environment it will live in.
When you test in production, you can target your internal teammates with the feature flag. This looks like turning the flag on for just them initially, testing the feature, resolving any issues, and then releasing the feature to your entire userbase with the click of a button from your feature flag platform, (like Split!). Once the feature has been living in production and has been released to 100% of your users, the flag can be deleted, as it is no longer needed. You can also decide to let the feature flag sit for just a couple of weeks after you finish testing to increase your confidence that the feature works in prod. Just set a task to go back and deprecate.
Using a Feature Flag as a Kill Switch
A kill switch is an easy, feature flag powered toggle that disables a feature. With the click of a button, you can turn on or off a feature in production without needing a lengthy release process.
If you’re using a feature flag as a kill switch, you wouldn’t want to delete it at all, so it will have no “done” criteria until or unless you deprecate that entire feature. For example, if you use the flag for permissions or entitlements, you need the flag there as long as those exist in production. You would remove the flag only if you decide that you no longer need that kill switch to be there. Long-lived flags such as permissions, entitlements, etc., can be kept in the codebase for as long as they’re useful.
Using a Feature Flag for A/B Testing
Feature flags empower your product teams by giving them the ability to grant exclusive access to a new feature to a select group of users. First, create specific user groups of the different segments that will receive the different treatments. Then, in the targeting rules section, you can add the user groups to the corresponding treatments.
Often, teams don’t decide success criteria ahead of time for the experiment they are running. This is problematic because you’re not following the rules of the scientific method. Before you run the experiment, you should define what your confidence interval is. Typically, if you run an A/B test, you keep running until you reach statistical significance. You leave it alone until that point. Once you’re done, then the experiment is complete.
Once you reach statistical significance in the experiment, you choose a winner and remove the losing code. Keep in mind that the experiment’s purpose might not be to release something but to gather information on prospective plans. Regardless, once the experiment is complete, you should delete the feature flag.
Using a Flag as a Release Toggle
Let’s say your team is working on building an app with both a frontend and a backend. Your frontend developer finishes her work before the backend developer. Instead of waiting for the backend developer to finish and then resolving merge conflicts, the frontend developer could merge her code to production behind a feature flag. When the backend developer is done with his part, he can merge his code with what has already been done. Then, when all the pieces are in place, you could release the entire feature and remove the feature flag once you have allocated 100% of your userbase to the new feature.
Overall Best Practices
Once a feature flag meets its definition of done, it’s essential to delete the flag not only from your feature flagging platform but also from your code. You don’t want to have stale code in your codebase, so you want to maintain that as well as possible.
Another best practice is to define done upfront rather than retroactively. This helps you plan ahead of time and be more efficient in your processes.
Learn More About Feature Flags
Feature flags are a great way to increase efficiency and speed while learning about your userbase through data.
- The Dos and Don’ts of Feature Flags
- A Quick Guide to Implementing Feature Flags with Spring Boot
- The Benefits of Feature Flags in Software Development
- Feature Flag Maintenance
- Pros and Cons of Canary Release and Feature Flags in Continuous Delivery
To stay up to date on all things testing in production and feature flagging, follow us on Twitter @splitsoftware, and subscribe to our YouTube channel!
Get Split Certified
Split Arcade includes product explainer videos, clickable product tutorials, manipulatable code examples, and interactive challenges.
Switch It On With Split
Split gives product development teams the confidence to release features that matter faster. It’s the only feature management and experimentation solution that automatically attributes data-driven insight to every feature that’s released—all while enabling astoundingly easy deployment, profound risk reduction, and better visibility across teams. Split offers more than a platform: It offers partnership. By sticking with customers every step of the way, Split illuminates the path toward continuous improvement and timely innovation. Switch on a trial account, schedule a demo, or contact us for further questions.