How to Implement Production-Ready Feature Flag Change Requests

Change requests or approvals help protect your feature flag changes by applying the four-eyes principle, also known as the two-person rule. This means that instead of making changes to your flag configuration directly, someone else must approve them first. Think of change requests for feature flags like pull requests for code. Not everyone uses them, but when you need review control, they’re useful.

In addition to enabling you to implement four-eyes approval for feature flag changes, when done right, change requests allow teams to:

• Preview feature flag configuration changes before applying them
• Scheduling a change to one or more feature flags in the future
• Safeguarding against making mistakes in addition to protecting as bad actors

Setting up a good change request process for feature flags isn’t easy. Some essential capabilities are needed to do it right. Read on to learn how to set up enterprise-ready feature flag change requests.

1- Approving a change to a single feature flag

First, you need to be able to change one flag through a change request. This includes enabling or disabling a flag, increasing rollout percentage, or adjusting individual user targeting. A good system makes this process straightforward and ensures that any change to a feature flag is reviewed and approved before it goes live.

2- Approving a change to multiple feature flags

What if you need to change two flags at the same time? Can your system handle it? Or do you need to submit separate change requests for each flag? You wouldn’t change your pull request code one file at a time, right? So, you shouldn’t have to change one flag at a time, either. Your change request system should support batch changes. This means you can change multiple flags in a single request.

3- Approving a change to who sees a flag

Segments are a popular way of grouping user targeting into reusable blocks so you can easily define who sees a particular flag. Almost every vendor supports them. However, it’s easy to overlook segments when using change requests. If you require change requests for enabling or disabling a flag, but not for who can see the flag, your configuration is only partially protected.

4- Approving a change to a user segment in addition to the flag configuration itself

In many instances, you want to change the flag configuration and who sees it at the same time. Ensure that your system allows segment and flag changes to be made together in a single change request. Very often, when adjusting targeting directly on a flag and modifying the segment, these should be done atomically. We’ve observed that some feature flag solutions recommend making two separate change requests: one for the segment and one for the flag configuration. However, we prefer to avoid having targeting rules in an undesirable state during the transition period.

5- Applying batch import operations to feature flags

Your enterprise-ready feature flag system should support batch operations between environments or different platform instances. You don’t want to move flag configuration one flag at a time. The import process should also be protected with change requests when migrating data. It is common to have tens of flags in one import change request. A comprehensive system allows for such extensive batch operations, ensuring that changes are reviewed and approved even during imports and migrations, maintaining data integrity and security across environments and instances.

6- Archiving feature flags

Archiving feature flags can affect what users see in production. It’s very easy to hide a feature accidentally for many users. With change requests enabled, archiving a feature should also go through a change request. It seems obvious, but some systems skip this step. Make sure your process includes it. A solid change request system covers archiving, ensuring no critical step is overlooked.

Summary

From the implementer’s perspective, change requests are one of the most complex parts of the feature flag system. Getting change requests right is nontrivial. When building your own feature flag solution or choosing a vendor, make sure that change requests don’t just tick a feature check box. Ensure your solution covers more than the most basic scenarios, which often is just a single feature flag change.

Want to protect your flags with the largest open-source feature flag solution? Try Unleash today.

Comparison of change requests between Unleash and LaunchDarkly

ChangeRequest/Approval capability for	Unleash	LaunchDarkly*
Single flag	✅︎	✅︎
Multiple flags at once	✅︎	❌
Segments (e.g. who sees a flag)	✅︎	❌
Flag and segment at the same time	✅︎	❌
Import flags	✅︎	❌
Archive flags	✅︎	❌

*Based on the operations available at: https://apidocs.launchdarkly.com/tag/Approvals