Testing with feature flags: 5 steps to get started

With the growing popularity of feature flags in the software development industry, many organizations are wondering how to start using them. As the saying goes, “imitation is the sincerest form of flattery,” so the best way to learn how to use feature flags is to look at how other organizations have successfully evolved their continuous delivery system to incorporate feature flags. This strategy will also provide insight into mistakes others have made and how your organization can avoid them.

Step 1: Implement Feature Toggles

It’s important to remember that feature flags exist as lines of code that dictate whether a feature is turned on or off for users. That means your first step into the world of feature flagging should start with developing a basic configuration setting in your feature flag management tool that will implement feature toggles.

Now, without ever writing any code, you’re able to control when your feature is active and when it’s inactive with the flip of a button. Here’s an example with React, but there are plenty of other SDKs.

Step 2: Target Internal Teammates

As I’ve discussed before, testing in staging environments is out, and testing in production is in. The best practice here is to keep the default rule of the feature flag off while still targeting the members of your team inside of the flag. This allows you and your team to safely and fully test your feature in production before a customer can ever see the feature.

Testing in production is important because it guarantees your features will work in the environments in which they live. It also increases developer confidence and the speed at which you can move the project along because developers spend more time creating new features and less time fixing bugs.

Step 3: Take Advantage of Automation

Long after your features have been released, you don’t want to worry about them. The best way to make sure things are working long term is through automation. During your release’s testing phase, target the automation bots inside the feature flag and task them with performing the test. Then, once you turn the feature flag on, you won’t need to make any additional changes, and the bots will continue to perform the same tests.

Step 4: Adopt An Approval Process for Code Control

Humans aren’t perfect, and we make honest mistakes all the time. As your organization’s use of continuous delivery increases, so does the chance of making mistakes. For example, a project manager may accidentally disable a feature while attempting to target a subset of users. An engineering team could accidentally enable another team’s feature prematurely. Or maybe the multiple feature branches you created are conflicting with your toggles.

You need to accept that accidents will happen, but you also need a system in place to review and approve new changes in order to catch them before they cause major harm. Treat your feature flag configuration the same way you would treat changes to your codebase. If you normally require two code reviews and approvals for your codebase, you should also require two code reviews and approvals for your feature flagging changes. Testing in production does increase release sensitivity, but adding a review process can mitigate disasters.

Step 5: Implement Canary Releases

Canary releases are intended to limit the blast radius in case something malfunctions with your feature. Even after going through the process of targeting your teammates in the feature flag, testing your code behind the flag in production, and turning on the feature in  production, there’s still a chance you'll find a bug in the feature. If that does happen, would you rather have 100% of your users encounter the faulty feature or 1% of your users? Canary releases provide that much-needed risk mitigation while testing in production.

Using your feature flag management system, set a specific percentage of users that will receive your feature once the flag is on. You can gradually increase that percentage as time goes by and your confidence in the feature improves. Be aware that because of their sensitivity, infrastructure and configuration changes should always be released through a canary.

One More Thing: Toggle Debt

Toggle debt can begin to accrue in a given codebase after you’ve been using feature flags for some time. It often shows up in the form of deprecated feature branches, experimental features never brought to fruition, or features that have since been eliminated or replaced. It’s important to create a habit of managing old toggles and making sure new flags don’t conflict with old flags. For more details on feature flag best practices, check out this video.

The most crucial thing to keep in mind while testing with feature flags is ensuring a positive user experience. By following these five steps, you’ll be on your way to becoming a feature flagging expert and creating an experience your customers will want to have time and time again.