Read more

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

Arne Hartherz
April 28, 2011Software engineer at makandra GmbH

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

Illustration UI/UX Design

UI/UX Design by makandra brand

We make sure that your target audience has the best possible experience with your digital product. You get:

  • Design tailored to your audience
  • Proven processes customized to your needs
  • An expert team of experienced designers
Read more Show archive.org snapshot

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 Show archive.org snapshot 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.

Arne Hartherz
April 28, 2011Software engineer at makandra GmbH
Posted by Arne Hartherz to makandra dev (2011-04-28 17:15)