4 ms·
No it's not. Everyone who loves feature flags has never done serious work. The amount of extra work / redundant code that has to be done to accommodate differen
by throw1234651234 4y ago
No it's not. Everyone who loves feature flags has never done serious work. The amount of extra work / redundant code that has to be done to accommodate different DB schemas / DTOs in addition to the "lol feature flag" on the front end is absurd.
- thejosh 4y agoIf your feature flags are behind such complexity you have a bigger problem than feature flags.
- throw1234651234 4y agoNote "serious work". If you are hiding a banner, an extra button that calls a service method used elsewhere, some text, etc - feature flag away. Real world problems tend to be, at the very least, "add some new fields to the form" - at which point you are messing with DB schemas OR following bad practices like making fields that should have no business being nullable accept nulls because "who knows if the feature flag is on". This quickly destroys normalization and data consistency.
- thejosh 4y agoRight... which is why I said It's a great way to do small-medium features.
- satyrnein 4y agoIf you want to do rolling/canary deployments without downtime, or gradual rollouts to subsets of users, or a/b testing, you will have multiple versions running in parallel against the same database. Plenty of "serious work" happens that way.
- throw1234651234 4y agoSame problem. Someone I used to work with wrote an article about it and you run into the same problem with A/B tests / canary deployments / etc - need to account for different DB schemas: https://medium.com/swlh/worthwhile-modern-deployment-strategies-a-full-guide-a692363de186 https://medium.com/swlh/worthwhile-modern-deployment-strateg...