See this card for how migrations are handled with Capistrano 3.
When deploying an application with "cap deploy" by default [1] you only deploy your code but do not run migrations. To avoid an application to be running with code which requires database changes that did not happen yet you should use cap deploy:migrations.
The problem
Let's say that you have something like that in your config/deploy.rb to create a database dump every time you deploy:
before 'deploy', 'db:dump'
This will not be called for cap deploy:migrations. The same applies to other things that are hooked similarly, like an after 'deploy', 'craken:install'.
How to avoid it
When looking at the default deploy recipe mind those three tasks:
| Task name | Called tasks | Note |
|---|---|---|
:update |
update_code, then symlink
|
Clones a new release, symlinks it to current but does not restart Passenger |
:default |
update (see above), then restart
|
This one is used when running cap deploy
|
:migrations |
update_code, migrate, symlink, restart
|
Prefer (see first paragraph) |
As we can see, the migrations task never calls deploy and thus would not run its before or after hooks. But, just like the default task, it calls update_code at the beginning, symlink to link the "current" path and restart once all done. -- Those are the hooks to go for [2], don't just use the deploy hook for important things.
So instead of...
before 'deploy', 'db:dump'
after 'deploy', 'craken:install'
after 'deploy', 'db:show_dump_usage'
...you say...
before 'deploy:update_code', 'db:dump'
after 'deploy:symlink', 'craken:install' # Capistrano 2.9.0
after 'deploy:create_symlink', 'craken:install' # Capistrano 2.12.0
after 'deploy:restart', 'db:show_dump_usage'
...and are able to run both cap deploy and cap deploy:migrations.
Note that we prefer to hook onto symlink for things that should happen once the application is successfully deployed. If you have tasks that inform you about something but not stop deployment (e.g. the above "show_dump_usage") you should consider hooking them after restart so your application starts up earlier.
[1] You may want to consider overwriting the default task to run migrations (instead of update and restart). This way you can say cap deploy to get the latest code on the server, migrate the database and restart as a default -- if that is what you want.
[2] You could hook your dump task before deploy:migrate but when using only cap deploy(:update) you can end up having new code online without a recent database dump. Almost always you would first update the code and then migrate -- making the deploy:update_code hook the better choice.
