3 ms·
> The trick is to separate the deployment of schema changes from application upgrades. So first apply a database refactoring to change the schema to support bot
by petargyurov 4y ago
> The trick is to separate the deployment of schema changes from application upgrades. So first apply a database refactoring to change the schema to support both the new and old version of the application
How do you deploy a schema that serves both old and new versions? Anyone got any resources on this?
- david422 4y agoYou only do additive changes. Only add columns etc. never remove them ... until all your old application code is no longer running.
- naasking 4y agoAnd you have to weaken your schema to allow nulls for the duration that old and new code are both running (and possible foreign key constraint failures).
- petargyurov 4y agoThanks. I thought it would be something... smarter. Not sure I like that, seems to come with a lot of caveats.
- xani_ 4y ago"smarter" means more code and that's rarely more maintainable. It's what you have to do if you want less downtime. Normally it shouldn't span much more than 2-3 versions of application and it's rare that the annoying kind (say writing same data to "old" and "new" column) happens.
- outworlder 4y ago> until all your old application code is no longer running. Or until it's been disabled by feature flags.
- rwiggins 4y agoThe application needs to be developed with this constraint in mind. I’ve spent quite a lot of time over the years doing blue/green deployment advocacy and awareness for developers in some orgs. It does sometimes substantially complicate the code to build both backward and forward compatibility, but it is so nice when done well.