62 lines
2.7 KiB
Markdown
62 lines
2.7 KiB
Markdown
<!-- START doctoc generated TOC please keep comment here to allow auto update -->
|
|
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
|
|
## Table of Contents
|
|
|
|
- [Why use feature flags?](#why-use-feature-flags)
|
|
- [Should feature flags be used for everything?](#should-feature-flags-be-used-for-everything)
|
|
- [References](#references)
|
|
|
|
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
|
|
|
|
# Why use feature flags?
|
|
|
|
- **Velocity**: coupled with a system to rapidly deploy configuration change,
|
|
it is usually much faster to disable new code by turning off a feature than
|
|
re-deploying all the code. This extra safety net helps developers be more
|
|
confident in their release, because they know they can roll back a change
|
|
very rapidly in case of error.
|
|
- **Testing**: the presence of a feature flag forces the feature owner to test
|
|
the flow. Without feature flags, the developer might deploy the change and
|
|
assume the absence of errors means the release was successful. Yet there's
|
|
numerous failure mode that don't raise explicit errors.
|
|
- **Code iterations**: because code can be kept hidden behind a feature flag
|
|
until it's ready to go live, developers can push smaller code changes that
|
|
are not fully integrated yet. Smaller pull requests ease the job of code
|
|
reviewers, make testing easier, and reduce the probability of a catastrophic
|
|
failure.
|
|
- **Gradual rollout**: feature flags enable gradual rollout, where a piece of
|
|
code is gradually activated, for instance on a per city basis, or on a per
|
|
user group basis. This builds confidence in the feature release process, and
|
|
allows the engineer to verify that the new implementation is actually better
|
|
(for instance, when coupled with A/B testing frameworks).
|
|
|
|
## Should feature flags be used for everything?
|
|
|
|
I don't think so. I think it's a matter of good judgment. Just like 100% test
|
|
coverage does not always make sense (provided lines that are not tested are
|
|
explicitly ignored), adding or not adding a feature flag is an engineering
|
|
decision.
|
|
|
|
When would I not use a feature flag?
|
|
|
|
- Simple changes: copy, logging, etc.
|
|
- When rolling back takes a few seconds
|
|
- Feature that is used only in asynchronous jobs that are safe to retry and
|
|
don't impact the user experience.
|
|
|
|
When should a feature flag be used?
|
|
|
|
- Large refactors
|
|
- Changing integration points
|
|
- Performance optimization
|
|
- New flows
|
|
|
|
## References
|
|
|
|
- Martin Fowler,
|
|
[FeatureToggle](http://martinfowler.com/bliki/FeatureToggle.html)
|
|
- Flickr, [Flipping Out](http://code.flickr.net/2009/12/02/flipping-out/): one
|
|
of the first articles on the topic.
|
|
- [Using Feature Flags to Ship Changes with
|
|
Confidence](http://blog.travis-ci.com/2014-03-04-use-feature-flags-to-ship-changes-with-confidence/)
|