31 lines
1.6 KiB
Markdown
31 lines
1.6 KiB
Markdown
|
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.
|
||
|
|
||
|
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/)
|