Re:How I learned to stop worrying and push to master
by mkdirp on Friday December 17, 2021 @06:20AM
(#29590712)
Parent commenter probably meant putting new features behind a flag. I work for a major feature management company and we heavily use our own platform. Yet we don't put "all code" behind feature flags but we do with features. It's nearly impossible to put "all code" behind feature flags.
Re:How I learned to stop worrying and push to master
by shawnps on Friday December 17, 2021 @08:16AM
(#29591662)
Right, basically this. If you're shipping something new that could affect production, put it behind a feature flag so the code paths that are already live are unaffected. Continuously ship small changesets so that it's easy to roll back if necessary.
Re:How I learned to stop worrying and push to master
by dpark on Friday December 17, 2021 @01:13PM
(#29595937)
> If you're shipping something new that could affect production…
Which, again, is everything. I’m all for feature flags, but they cover very specific cases. There are many changes that feature flags cannot cover. The addition of the feature flags itself can introduce bugs. They are a great feature but only one small piece of protecting production.
How is that even possible? A comma change in a feature can break things, are you going to put that change behind a feature flag?
"New code" isn't just "new files/functions", so it's not always feasible to keep it behind flags, unless you use a "copy on write" methodology to all code.