For GitLab we have a somewhat special approach to allow us to perform zero downtime migrations. Basically we have two types of migrations: 1. Regular migration

For GitLab we have a somewhat special approach to allow us to perform zero downtime migrations. Basically we have two types of migrations: 1. Regular migrations (located in db/migrate) 2. Post-deployment migrations (located in db/post_migrate) Post-deployment migrations are mostly used for removing things (e.g. columns) and correcting data (e.g. bad data caused by a bug for which we first need to deploy the code fix). The code for this is also super simple: # Just dump this in config/initializers unless ENV['SKIP_POST_DEPLOYMENT_MIGRATIONS'] path = Rails.root.join('db', 'post_migrate').to_s Rails.application.config.paths['db/migrate'] << path ActiveRecord::Migrator.migrations_paths << path end By default Rails will include both directories so running `rake db:migrate` will result in all migrations being executed as usual. By setting an environment flag you can opt-out of the post-deployment migrations. This allows us to deploy GitLab.com essentially as follows: 1. Deploy code to a deployment host (not used for requests and such) 2. Run migrations excluding the post-deployment ones 3. Deploy code everywhere 4. Re-run migrations, this time including the post-deployment migrations We don't use anything like strong migrations, instead we just documented what requires downtime or not, how to work around that (and what methods to use), etc. Some more info on this can be found here: * https://docs.gitlab.com/ee/development/what_requires_downtime.html#what-requires-downtime https://docs.gitlab.com/ee/development/what_requires_downtim... * https://docs.gitlab.com/ee/update/README.html#upgrading-without-downtime https://docs.gitlab.com/ee/update/README.html#upgrading-with... * https://docs.gitlab.com/ee/development/post_deployment_migrations.html#post-deployment-migrations https://docs.gitlab.com/ee/development/post_deployment_migra...