back

by locknitpicker·7d ago·view on hn ↗
> That's a good point about not using feature flags to mitigate risk, and how rollbacks are a better alternative. T

I doubt anyone making this sort of claim has any professional experience maintaining any sort of user facing software.

Features that require cross-system support can't easily be pulled out with a revert, particularly in CICD systems where cherry picking a revert can easily be incomplete/miss a bug fix and reverting the whole history will end up inadvertently pulling out some other feature.

Also, a deployment takes time, particularly in services with more than one deployment region. Moreso if n>1 separate systems are involved.

In comparison, runtime config changes are enforced in a fraction of the time, and pulling out the code just involves a roll forward. Simple.

1 comments
Both Google and Amazon do rollbacks instead of feature flag switches. I’m pretty sure they have some experience maintaining user-facing software.
> Both Google and Amazon do rollbacks instead of feature flag switches.

I'm sorry, but you're completely wrong. I know for a fact that Amazon uses extensively a A/B testing system for feature flags. Others in this discussion already mentioned it.

I’m not wrong. They do use feature flags, but not as a substitute for rolling back failed or buggy deployments. They (and Google too) use feature flags in the ways according to the best practices discussed in the article. Google also covers this well in their highly-regarded Site Reliability Engineering book.

Source: worked at AWS for 7 years.

And knock it off with the attitude.