Data models change and evolve with your application.There’s plenty of tools that keep track of database schemas and automatically generate scripts to upgrade or downgrade them.It’s common for developers to run a migration at the start of their app before running app code.Our author explains two common problems with this approach.Modern day production deployments and horizontal scaling can get you into a race condition.You start assuming that new code will only ever run with the new schema.You can decouple migrations from code changes by disabling parallelism during this time.Make it a separate command or lock the database during the upgrade.We can easily implement locking ourselves in any language.Use Redis locks if you’re ok with something external to the DB.Use the DB itself by writing to an extra table to say that you’re upgrading it.Plan your deployment appropriately so you can run old code with new by making migrations additive in the short term.Using a script at startup that optionally performs the migration based on an environment variable integrates wel with Docker and cloud services.Upgrades of both code and data should be part of your testing BEFORE releasing to production.
View all episodes
