This has been discussed in #167, but that PR has since been abandoned. I am moving the discussion here.
Right now capistrano-rails attempts to run database migrations on every deploy. This is undesirable for some applications according to the following comments (see below, copied and pasted from #167).
Ideally capistrano-rails would provide both of these things:
- A way to turn auto-migrations off; and
- A task to trigger a migration manually
Sometimes you may need to run migrations after the actual deploy. For example, if a migration locks the DB, etc. A common case is adding an index to your DB, the functionality is the same, but the addition can cause locks. In this case you may need to run the migration later, but still need to deploy the code.
Our workflow is this: simple migrations (on small tables) can be done using rake db:migrate, but larger ones need to be run manually using third-party tools like, in our case for MySQL, https://www.percona.com/doc/percona-toolkit/2.1/pt-online-schema-change.html. If accidentally someone in our team runs such a larger migration, it could cause a lot of trouble for us (we recently had 30 minutes downtime because of a larger ALTER TABLE on our MySQL Galera cluster).
This has been discussed in #167, but that PR has since been abandoned. I am moving the discussion here.
Right now capistrano-rails attempts to run database migrations on every deploy. This is undesirable for some applications according to the following comments (see below, copied and pasted from #167).
Ideally capistrano-rails would provide both of these things: