Posted about 6 years ago. Visible to the public.

Which Capistrano hooks to use for events to happen on both "cap deploy" and "cap deploy:migrations"

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.

makandra has been working exclusively with Ruby on Rails since 2007. Our laser focus on a single technology has made us a leader in this space.

Author of this card:

Arne Hartherz
Last edit:
over 2 years ago
by Martin Straub
About this deck:
We are makandra and do test-driven, agile Ruby on Rails software development.
License for source code
Posted by Arne Hartherz to makandropedia