DEV Community

Discussion on: Gamifying Continuous Integration

Collapse
 
jappyjan profile image
jappyjan

Hmm seems legit for a new feature/replacement...

But what about database migrations/changes...

What if a new feature requires a database change which would break the previous logic? In this case Feature flags are worthless and the only way of handling it would be a second (or even one for every feature) database...

Or do I get it wrong and there is also a nice solution to this?

Thread Thread
 
quii profile image
Chris James

I've found it is usually possible with some creative coding to keep db changes backward compatible and this is usually a much safer way of working anyway - irrespective of how you work

e.g keep the old field, introduce new field, code feature toggles against using both and then once you're happy with the new one you can safely delete.

Sometimes though, maybe something doesn't fit into small iterative changes. I would contest this is rare but if it does... well take the hit. Acknowledge it isn't great in this case. One pair works on the awful thing that is perhaps on a branch for a week. They have to contest with merging things etc. You get through it and move on.