« back to all cards in this deck
Posted over 3 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' 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.

Growing Rails Applications in Practice
Check out our new e-book:
Learn to structure large Ruby on Rails codebases with the tools you already know and love.

Author of this card:

Avatar
Arne Hartherz
About this deck:
We are makandra and do test-driven, agile Ruby on Rails software development.
Posted by Arne Hartherz to makandropedia