Considering Capistrano for Drupal site deployment

All you need is Capistrano and an account on the deploy machine. This can be used and extended to deploy to several servers (also at once), move databases around, etc. The gain is that you don't need to login to the server. We can talk about that interesting technique tomorrow.

A nice feature is the ability to roll back to an older version if something bad happens. If this happens during deploy it rolls back automatically.

Stefan

http://tempe.st/category/drupal/

My head always begins to spin when looking at options for development and deployment tools, so I turn to the author of dbscripts.

if used for Drupal, do you think it's compatible/enhancing, overlapping, or incompatible/redundant with dbscripts?

KM: it would likely be compatible

they are two different things

dbscripts is for version control and merging development and production

capistrano is for deployment

That would be kinda like saying "should we use capistrano instead of svn or git?"

BM: yeah... i was pretty sure, but i've only looked at Capistrano for 5 minutes, heh -- yeah, Capistrano just moves databases around, though the stuff Stefan is looking at uses it for making dev installs

heh heh... well, unfortunately, yeah-- we use SVN for deployment, currently

KM: yeah, I also use SVN for deployment

and we used to use SVN for deployment for [a more complex project]

it just grew so complicated that it was no longer feasible

installing software, configuration, databases, etc

BM: yup... that's why i put everything, settings.php and the apache configuration file, into SVN. And then made our test and production servers identical in setup, heh. We'll see what Capistrano can do for us, and then look at dbscripts too, for more.

KM suggests: use capistrano for the server deployment, and maybe continue to use svn/git for the website deployment

Here's an example cap file modified for Drupal that Stefan attached to his message:

load 'deploy' if respond_to?(:namespace) # cap2 differentiator
# Standard configuration
set :user, "stefan"
set :password, "nottelling"
set :application, "drupal-6"

# I like to deploy the code in /var/apps
# and then link it to the webserver directory
set :deploy_to, "/srv/#{application}"

# SCM Stuff configure to taste, just remember the repository
# here I used github as main repository
set :repository,  "git://github.com/freudenberg/scf.git"
set :scm, :git
set :branch, "master"
set :repository_cache, "git_master"
set :deploy_via, :remote_cache
set :scm_verbose,  true

# Two servers, double fun
# You really don't need app, web and db here,
# but I used all of them just to be sure.
# Usually only web is ok.
role :app, "server.grassrootsconnection.org", :primary => true
role :web, "server.grassrootsconnection.org", :primary => true
role :db, "server.grassrootsconnection.org", :primary => true

after 'deploy:setup', 'drupal:setup' # Here we setup the shared files directory

# Before restarting the webserver we fix all the
# permissions and then symlink it to production
before 'deploy:restart', 'mikamai:permissions:fix', 'mikamai:symlink:application'

namespace :drupal do
  # shared directories
  task :setup, :except => { :no_release => true } do
    sudo "chown -R #{user}:#{user} #{deploy_to}"
  end
end

namespace :deploy do
  # adjusted finalize_update, removed non rails stuff
  task :finalize_update, :except => { :no_release => true } do
    sudo "chmod -R g+w #{latest_release}" if fetch(:group_writable, true)
  end

  task :restart do
    # nothing to do here since we're on mod-php
  end
end

namespace :mikamai do
  # symlinking to production
  namespace :symlink do
    task :application, :except => { :no_release => true } do
      sudo "rm -rf /var/www/drupal-6/profiles/scf"
      sudo "ln -s #{latest_release} /var/www/drupal-6/profiles/scf"
    end
  end

  # change ownership
  namespace :permissions do
    task :fix, :except => { :no_release => true } do
      # sudo "chown -R www-data:www-data #{latest_release}"
    end
  end

end

Resolution