Using Feature Flags to Boost Testing and Deployment

Feature flags are a useful way of deploying software quickly, without skimping on quality.

A feature flag is a configuration setting that allows you to turn a given feature on or off. Let's say, for example, you're building a new screen into your product. You could use a feature flag to make that screen accessible if the flag is on or inaccessible if the flag is off.

This is useful because testing becomes faster and easier. With feature flags, there is no need for a feature to be complete before you can start testing. As soon as the first piece of code is merged, you can turn the flag on in your test environment and begin. Remember, even an incomplete feature is testable!

Feature flagging also reduces risk. Of course problems in your production environment are undesirable, but they do happen. Feature flagging means that if there’s a problem with a live feature, it can be turned off easily. This, in turn, means a smaller set of customers will be affected, and less effort will be required to fix the issue.

And because developers can continuously push code into production, your master branch is always up to date. This means the likelihood of merge conflicts or integration issues is reduced.

One thing I’ve learned working with feature flags is the importance of testing “flagged off” every time you release. If the flag itself doesn’t work or the feature hasn’t been put behind the flag correctly, it could result in disaster. It’s sensible to do a quick check when releasing that there is no “flag on” behavior visible.

If you’re shipping to production often, you’ll also find yourself needing to test quickly. Once you’ve done your “flag off” test, avoid the temptation to do any “flag on” testing yet. You already know the feature is safe, so you can release to production confidently. Then you can turn the flag on in your test environment, and you now have much more time and freedom to explore the feature.

Finally, feature flagging by nature introduces technical debt into your system. Say a feature has been deployed to production. If the feature flag has been switched on for some time without any problems, then it’s safe to say you don’t need that flag any more.

A useful practice is to include removing the feature flag in your definition of “done” or “feature complete.” Left unattended, you could end up with a messy code base full of unnecessary feature flags.

The use of feature flags will mean you can ship to production with greater frequency and greater confidence. Implementing feature flags could mean some changes to the way you test, but it also will mean a more robust product and greater value to your organization.

• Login or Join to add your comment