4 ms·

Database migrations. Especially zero downtime multi-phase schema migrations. Rather than make all changes at once, do smaller incremental changes to allow old c

Database migrations. Especially zero downtime multi-phase schema migrations. Rather than make all changes at once, do smaller incremental changes to allow old code, and new code to worth with the database at the same time, before removing old code, and finally removing the parts of the database schema which is no longer used. For example, i just googled for "zero downtime schema migration" and this covers the topic relatively well: https://blog.philipphauer.de/databases-challenge-continuous-delivery/ https://blog.philipphauer.de/databases-challenge-continuous-...

insulanian 8y ago
>We change the schema in a way that is still compatible with the old version of the schema. Sure, this won’t work in many cases, but in some. In my experience, doing DB migrations w/o downtime is rarely worth it and involves big risks of actually ending up having long unplanned downtime due to the process being prone to errors. Large majority of schema changes can be performed very quickly and couple of seconds downtime is acceptable in most cases. Long story short: Don't do DB migrations without downtime unless you absolutely need to. P.S. If your business guy is requesting deployment w/o downtime, make sure to have a conversation with him to understand why is that so. In majority of cases they make it more dramatic than it really is.