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
Stay up to date
Don’t miss out! Subscribe to our digest to get the latest about feature flags, continuous delivery, experimentation, and more.
The increased usage of feature flags and canary releases (also “canary deployments”) in software development has had a tremendous impact on the overall release process for software companies globally. These canaries and feature flags allow you to test your features in production , convert your monolith to microservices, perform A/B…
The ability to immediately propagate changes to SDKs is important to many customers, so we decided to invest in a real-time streaming architecture.
As companies implement more innovative practices, they typically realize the faults of using an imperfect environment, like staging. Staging environments are expensive and they often do not match the behavior of production which leads to faulty test results. They also don’t provide any confidence that your features are working before…