Start testing in production with feature flags by targeting teammates, using canary releases, automating flows, and managing toggle debt effectively.
TL;DR
- Feature flags enable safe testing in production by controlling feature visibility at runtime without code deployments.
- Target internal teammates first to validate features in production environments before exposing them to end users.
- Automate user flows with bots targeted inside feature flags to ensure continuous validation after release.
- Implement approval workflows for flag changes to prevent accidental rollouts and maintain release quality standards.
- Use canary releases starting at 1 to 5% of traffic to limit blast radius when issues occur post-deployment.
- Manage toggle debt proactively by removing deprecated flags to prevent code complexity and conflicting configurations.
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.
Frequently Asked Questions
Q: What does it mean to test in production with feature flags?
A: Testing in production with feature flags means deploying new code to your live production environment while controlling who sees it through conditional logic. Feature flags act as runtime switches that let you enable features for specific users, such as internal teams, beta testers, or a small percentage of customers, while keeping them hidden from everyone else. This approach allows you to validate functionality in the real production environment where actual users interact with your application, without the risk of exposing untested features to your entire user base.
Q: How do feature flags reduce deployment risk?
A: Feature flags reduce deployment risk by decoupling code deployment from feature release. You can deploy code to production with the feature flag turned off, test it internally, and then gradually roll it out using canary releases that start at 1 to 5% of traffic. If issues arise, you can instantly turn off the flag without rolling back code or redeploying, minimizing downtime and user impact. This incremental approach limits the blast radius of potential failures.
Q: What is toggle debt and how do I manage it?
A: Toggle debt refers to the accumulation of outdated or unnecessary feature flags in your codebase. Over time, deprecated flags from completed releases, abandoned experiments, or replaced features can clutter your code and create maintenance burden. Manage toggle debt by establishing a flag lifecycle policy: remove flags immediately after 100% rollout completion, archive experimental flags that never launched, and conduct quarterly audits to identify and clean up stale flags. Proper flag naming conventions and documentation also help teams track which flags are still active.
Q: Should every feature be behind a feature flag?
A: Not every feature requires a feature flag, but high-risk changes should be. Use feature flags for major feature launches, infrastructure changes, database migrations, customer-facing UI changes, experimental features, and anything that could impact system stability or user experience. Small bug fixes, internal tooling updates, or low-risk cosmetic changes typically do not need flags. The decision should be based on deployment risk, rollback complexity, and whether you need gradual rollout control.
Q: How do canary releases work with feature flags?
A: Canary releases with feature flags involve targeting a small percentage of your user base (typically 1 to 5% initially) to receive the new feature while monitoring key metrics like error rates, performance, and user engagement. If metrics remain healthy, you gradually increase the percentage (10%, 25%, 50%, 100%) over hours or days. Feature flag platforms provide built-in percentage-based targeting, automated monitoring, and instant rollback capabilities, making canary releases safer and more controlled than traditional deployment strategies.