3 ms·
It seems like a tall order if not impossible to put every potentially breaking change or fix behind a feature toggle, and even if were possible to map the effec
by jacknews 3y ago
It seems like a tall order if not impossible to put every potentially breaking change or fix behind a feature toggle, and even if were possible to map the effects of every change, why bother deploying code that has no effect?
It's fair enough if you're going to switch on complete features for a subset of users, but if it's just to hide incomplete parts of a feature?
The practice seem like all risk for no gain.
- williamdclt 3y agoIt's a pretty common use of toggles, really! It has many upsides: decoupling deployment of code from feature release (useful for many reasons eg giving PMs control over the feature release), gradual feature rollouts, fast feature rollbacks, breaking up big features over multiple small PRs (eg each implementing a different part of the logic/UI), deploying "risky" code knowing you can enable/disable it instantly... We use this extensively at work, and wouldn't go back. You call it "just hiding incomplete parts of a feature", but for us that was a huge improvement in workflow. The real downside is that these flags tend to outlive their purpose; they don't get cleaned up as soon as they should.
- doabitnormalman 3y agoI would like to introduce feature toggles at my place of work as well, but I'm worried we will get massive amounts of if-statements everywhere. Is there a smart way of implementing (many) feature toggles?
- jacknews 3y agoYes I agree about staged rollouts, ability to 'unrelease' features, and so on. But let's say you're part way through implemeting a new feature, and you need to alter a db table. How do you know that won't affect existing code (apart from tests)? How do you put that behind a feature flag anyway? As I said, deploying a change like this, without it being used for anything, seems like all risk and no gain.