It doesn’t really matter how you manage changes to feature flags, but using version control gives you a couple of nice benefits:
* gives developers the opportunity to describe their change
* let’s you roll back a problematic patch
* blame and bisect problematic patches
Ideally, you should also be able to see your feature flag changes in prod much faster than it takes to cut a release. You need this in order to be able to quickly roll back bad features.
Awesome, that’s makes total sense. Am I right in thinking the practices described here at Facebook are more like progressive delivery?
As in, instead of adding code to call out to some external feature flag or configuration system, new changes are deployed automatically in isolation and requests are routed to them progressively for larger and larger cohorts? All while validating the health of the change automatically?
Comments
It doesn’t really matter how you manage changes to feature flags, but using version control gives you a couple of nice benefits:
* gives developers the opportunity to describe their change
* let’s you roll back a problematic patch
* blame and bisect problematic patches
Ideally, you should also be able to see your feature flag changes in prod much faster than it takes to cut a release. You need this in order to be able to quickly roll back bad features.
See https://engineering.fb.com/2017/08/31/web/rapid-release-at-m...
Awesome, that’s makes total sense. Am I right in thinking the practices described here at Facebook are more like progressive delivery? As in, instead of adding code to call out to some external feature flag or configuration system, new changes are deployed automatically in isolation and requests are routed to them progressively for larger and larger cohorts? All while validating the health of the change automatically?