A RailsConf talk by Kir Shatov (blog post - http://kirshatrov.com/2018/04/01/async-migrations/) got me thinking about database migrations. Shopify has written a custom method for running migrations asynchronously and separate from deploys. They try to make all migrations backward compatible so both old and new code can work (no renaming or deleting columns). GitLab has also done some work on this with a concept of standard migrations and post-deploy asynchronous migrations. I'm sure other companies have done some similar custom solutions internally to minimize downtime.
I think this illustrates that there ought to be a generic and builtin solution for no downtime migrations in Rails. In my mind there are at least two strategies that should be considered when attempting a solutions here - continuous deployment/Kubernetes and periodic/standard deployment. Shopify's migration solution seems to cater well to continuous deployment/Kubernetes because a background job runs periodically to check for new migrations. GitLab's caters more to standard deployments where we want to deploy some code with database changes and then immediately come back post-deploy and clean up the stuff we no longer need. I bet we can come up with a solution that addresses both situations. However, Kubernetes is the perfect driver for change here because the deployment strategy almost guarantees you will have different versions of code running together while a deploy is in progress. So, two questions: 1. Is this something that we should solve in Rails? 2. What are some thoughts on *how* to solve this? -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at https://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
