dan/blog

Started hacking Capistrano today.

Capistrano makes it easier to do things on remote servers because it looks like you’re doing it on your local machine. Instead of connecting to the server (e.g. ssh), finding the appropriate directory and running the appropriate commands, you run a capistrano task locally. 

This is a lot like the build system make (or Ant, or rake or any other variant) in that it handles boring tasks for you. The difference is that Capistrano concentrates on doing boring things on remote servers.

It is most often used for deploying Rails apps, but can be used for anything that requires lots of work on remote servers. Think of it as doing the heavy lifting involved in deploying your app.

In rails you can run the following to prepare your app for deployment:

# capify .

I tried this on our PHP projects and everything after this in these instructions worked fine, up to deploying the app at which point rails uses “rake db:migrate” and “rake start” to install an app. In my PHP project these commands are meaningless so Capistrano just bailed.

I should point out now that I am not fixing a bug – I’m hacking Capistrano / capify to work with our non-Rails apps.

I should also point out that I previous posted a stupid way of doing this, involving hacking the source. The following is the grown-up way of doing this.

Inside Capistrano’s file deploy.rb, you’ll find the migrate and start tasks. I don’t want these – the only thing that capistrano will do for me is deploy the app and update it.

To get ride of these, add the following to your config/deploy.rb file:

desc "Do nothing"
  deploy.task :restart, :roles => :app do
    # ...do what you like here...
  end

 
What this means is that I can deploy my PHP application with the command:

cap deploy

cap deploy:rollback