Hacker News Reader

Comment by petargyurov | Hacker News Reader

> 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?

View on HN

You only do additive changes. Only add columns etc. never remove them ... until all your old application code is no longer running.

And 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).

Thanks. I thought it would be something... smarter. Not sure I like that, seems to come with a lot of caveats.

"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.

> until all your old application code is no longer running.

Or until it's been disabled by feature flags.

The 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.

Reply on news.ycombinator.com