To understand how businesses can begin using feature flags, let’s look at a typical case of an organization evolving a continuous delivery system using feature flagging from the ground up. By analyzing a system taking shape, we can identify some of the common mistakes that software development teams make and how to avoid them.
Use Feature Flags/Toggles
Since feature flags exist as lines of code that govern whether a given feature is active or not, the first step you should take is creating a simple configuration setting that will implement feature toggles. This will allow you to turn on or off a feature in your application without writing any code.
This can be done easily through the Split UI. Here’s a step by step guide on how to implement feature flags with React.
Target Teammates Inside the Feature Flag
When you target individuals inside of a feature flag before feature release (while the feature flag is off), you can test your features in production before they go live to your customers. This will ensure that your features are working in the environment that your features will live in. It will also increase developer confidence before release and increase your velocity in each sprint, because you will spend less time fixing bugs and more time creating new features.
Automate Your User Flows
In order to validate the functionality of your features long after you release them, automation needs to be put into place. In the testing phase of your release, you should target your automation bots inside your flag and use those bots to perform your tests. That way, after you turn your feature flag on, no changes will be necessary and your tests can continue to run with the same bots.
Control Your Code Deployment with Approval Flows
As the company’s adoption of continuous delivery grows, mistakes begin to occur. A PM targeting a subset of users accidentally disables a feature for all of them. An engineering team enables another team’s feature by accident. Multiple feature branches create conflicting toggles or early attempts at A/B testing are poorly targeted. To avoid these mistakes, use approval flows to have an extra set of eyes on your changes. Changes to your feature flag configuration should be treated as changes to your codebase. If you normally require two code reviews and approvals for your codebase, you should require two code reviews and approvals for your feature flagging changes as well. When testing in production, sensitivity for releases is increased, so having this extra step is crucial.
Use Canary Releases
When you use a canary during release, you limit the target audience in case something goes wrong with your feature. If you go through the process of targeting your internal teammates in the feature flag, testing your code behind the flag in production, and releasing that feature to prod, and you still manage to find a bug after release, do you want 100% of your users to encounter that bug, or 1%? Using canary releases provides risk mitigation when testing in prod. Through the Split UI, you can allocate a specific percentage of traffic that will receive the treatment once the flag is on. As time goes on and you gain confidence in the feature and the product, you can slowly increase that percentage. Note that infrastructure and configuration changes should always be released through a canary due to their sensitivity.
Read more about how using Split can help your organization experiment with new software features.
A Word on Toggle Debt
After using feature flags for some time, a given code base will begin to accrue what is known as toggle debt in the form of deprecated feature branches, experimental features never brought to fruition, or features that have since been eliminated or replaced. A critical aspect of a well-evolved system is managing old toggles and making sure none of the current flags conflict with previous ones. Be sure to watch our video on Feature Flag Maintenance for more detailed info!
Learn More About Testing in Production with Feature Flags
Excited about being able to test in production?
- Check out our video on Feature Flag Maintenance that goes into more detail about how to handle your feature flags in production
- Read our breakup letter to staging
- Read more about feature flags here
And as always, we’d love to have you follow along as we produce new content. Catch us on Twitter @splitsoftware, or on our YouTube channel! To get started with feature flags, try Split for free!
Get Split Certified
Split Arcade includes product explainer videos, clickable product tutorials, manipulatable code examples, and interactive challenges.
Switch It On With Split
The Split Feature Data Platform™ gives you the confidence to move fast without breaking things. Set up feature flags and safely deploy to production, controlling who sees which features and when. Connect every flag to contextual data, so you can know if your features are making things better or worse and act without hesitation. Effortlessly conduct feature experiments like A/B tests without slowing down. Whether you’re looking to increase your releases, to decrease your MTTR, or to ignite your dev team without burning them out–Split is both a feature management platform and partnership to revolutionize the way the work gets done. Switch on a free account today, schedule a demo, or contact us for further questions.