principleModerate
What is a 'Feature Flag Toggle' and when to use them (or not)?
Viewed 0 times
whatflagnotwhenandusethemtogglefeature
Problem
There are some questions about
Questions:
feature flag toggles, such as:- How to persuade developers to start using feature flag toggles?
- How to use feature flag toggles?
Questions:
- What is actually a "feature flag toggle" (in the context of DevOps)?
- Why are they used?
Solution
Without repeating the content of https://martinfowler.com/articles/feature-toggles.html, since it is an amazing in-depth explanation on what feature flag toggles are. I will just focus on the DevOps aspects.
According to the 2014 State of DevOps Report prepared by PuppetLabs, there are four major metrics to measure IT performance:
These also contribute to organisational performance overall. So it means that if your IT is doing great on these metrics, your bottom line gets more $$$.
Continuous Delivery is enabled by these metrics, and has been described in depth in the book Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation by Jez Humble.
In context of Continuous Delivery, there is an important distinction that differentiates it from Continuous Deployment. And that is the decision when to do a release of features (to customers).
Keeping changes smaller in size, and deploying (copying code) half-baked features to production systems with a feature flag toggled off allows to shorten lead time for changes.
When features are finally finished, doing a release is a decision left to the business. Maybe a release of a new feature needs to be aligned with some marketing, or a release in another part of the business like a feature in the mobile app.
Features can be released using A/B experiements to only a part of the customer base, or to specific people, or even direct to general availability (GA). Although releasing to GA is often done only after there is enough certainty that the feature works as expected. One might argue that this in effect affects release frequency to be higher.
This decoupling of release and deploy is almost impossible to achieve without feature flag toggles.
Naturally when no deployment is required to toggle a feature off, then the time to restore service is lowered substantially.
And by using feature flags that release features to a small slice of the customer base, the change fail rate metric can be improved significantly as well.
So a simple mechanism called feature flag toggles enables much better IT performance, and in turn improves organisational performance overall.
Great example of how this is done in real companies can be found at Flickr (on of the earliest public posts on the subject), and at Etsy. But many others have adopted the practice and talked about it in length, for example the famous engineering culture at Spotify videos.
Etsy are showing off their internal tool to manage feature flags, called Catapult, in multiple presentations found around the web. And Intuit release an open-source tool called Wasabi that helps manage feature flags.
According to the 2014 State of DevOps Report prepared by PuppetLabs, there are four major metrics to measure IT performance:
- Lead time for changes
- Release frequency
- Time to restore service
- Change fail rate
These also contribute to organisational performance overall. So it means that if your IT is doing great on these metrics, your bottom line gets more $$$.
Continuous Delivery is enabled by these metrics, and has been described in depth in the book Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation by Jez Humble.
In context of Continuous Delivery, there is an important distinction that differentiates it from Continuous Deployment. And that is the decision when to do a release of features (to customers).
Keeping changes smaller in size, and deploying (copying code) half-baked features to production systems with a feature flag toggled off allows to shorten lead time for changes.
When features are finally finished, doing a release is a decision left to the business. Maybe a release of a new feature needs to be aligned with some marketing, or a release in another part of the business like a feature in the mobile app.
Features can be released using A/B experiements to only a part of the customer base, or to specific people, or even direct to general availability (GA). Although releasing to GA is often done only after there is enough certainty that the feature works as expected. One might argue that this in effect affects release frequency to be higher.
This decoupling of release and deploy is almost impossible to achieve without feature flag toggles.
Naturally when no deployment is required to toggle a feature off, then the time to restore service is lowered substantially.
And by using feature flags that release features to a small slice of the customer base, the change fail rate metric can be improved significantly as well.
So a simple mechanism called feature flag toggles enables much better IT performance, and in turn improves organisational performance overall.
Great example of how this is done in real companies can be found at Flickr (on of the earliest public posts on the subject), and at Etsy. But many others have adopted the practice and talked about it in length, for example the famous engineering culture at Spotify videos.
Etsy are showing off their internal tool to manage feature flags, called Catapult, in multiple presentations found around the web. And Intuit release an open-source tool called Wasabi that helps manage feature flags.
Context
StackExchange DevOps Q#344, answer score: 14
Revisions (0)
No revisions yet.