views:

100

answers:

1

A lot of Capistrano example recipes include a :db role. By default the deploy task exports the app code to all hosts in all roles. So that suggests that it's typical for people to keep a copy of their app on the DB host. Also, in Capistrano's distributed deploy.rb recipe, :deploy:migrate looks like this:

task :migrate, :roles => :db, :only => { :primary => true } do
  # ...
end

My question is, why is it done like that? Wouldn't it be cleaner to keep app code off the DB host (which might not even have Ruby installed) and run migrations from the production box?

+7  A: 

The db server runs migrations because it is the one 'responsible' for the database(s).

One could also imagine security policies that only allows for creating/dropping/changing of tables from the database server itself.

There might even be slight performance gains if there is data being loaded during a migration, although that is a terrible idea to begin with.

If you have the need to reference your database host and do not need a copy of the code on it you can use something like this:

role :db, 'dbhost', :no_release => true

Sample code to run migrations on an application server:

role :app, 'apphost', :runs_migrations => true
task :migrate, :roles = :app, :only => {:runs_migrations => true } do
  #...
end
Patrick
Nice, I didn't know about the :no_release option.
Sarah Mei