Not logged in (Log in or Sign up)

unwwwritten

Capistrano rocks!

A few years ago, I stopped playing golf. Not really as a conscious decision, I just didn't quite have the time (or money) for it. If When I do return to it, I intend on taking lessons as if I had never played -- I actually used to play a LOT. The reasoning for this is that, I want to make sure I'm doing things right... and my current swing is borne out of a whole lot of self-teaching, so it is full of problems. If Tiger Woods can re-invent his swing over and over, so can I right? So, why not start from the beginning.

Why am I talking about my (horrible) golf swing? Read on...

As I worked on deploying the beginnings of a side-project I'm working on, I once again decided to use Capistrano. I say "decided", because, well... really there's no choice (for me). Capistrano does what it does well. It works. I already know how to use it. Enough reasons?

Well, I recently saw a post where Jamis Buck (the author) announced that the documentation for Capistrano was going to receive some loving, and that he was working on a From the Beginning document. So, despite my previous statement that I "know" how to use Capistrano, I decided to start "from the beginning".

Having worked my way through it, I'm going to repeat myself... CAPISTRANO ROCKS!

My whole recipe to deploy my application onto my new slice (at slicehost.com -- which, by the way, I'm totally impressed with) amounts to the following...

   1  set :application, "application"
   2  set :repository, "git@github.com:user/#{application}.git"
   3  set :scm, :git
   4  set :deploy_via, :remote_cache
   5  server "domain.com", :app, :web, :db, :primary => true
   6  
   7  after "deploy:update_code", "deploy:db:symlink"
   8  
   9  namespace :deploy do
  10    namespace :db do
  11      desc <<-DESC
  12        Updates the symlink to database.yml. When  you deploy a new version, \
  13        this task's job is to update the `config/database.yml' symlink \
  14        to point at the shared version. You will rarely need to call this task \
  15        directly; instead, use the `deploy' task (which performs a complete \
  16        deploy, including `restart') or the 'update' task (which does everything \
  17        except `restart').
  18      DESC
  19      task :symlink, :except => { :no_release => true } do
  20        run "ln -fs #{shared_path}/config/database.yml #{latest_release}/config/database.yml"
  21      end
  22    end
  23  end

The changes the standard recipe outlined in Jamis's article are...

  1. I'm using git (on github.com) instead of svn, so the :scm variable has to be set and my :repository has to be set to the clone url for my git repository.

  2. I had to create an ssh keypair on my deployment server and paste it to my project's deploy keys on github.com in order to grant access to my private repository -- if you're using a public repository, this probably is not necessary.

  3. I set :deploy_via to :remote_cache in order to (hopefully) speed up deployment somewhat (the entire repository does not have to be cloned each time, instead it just gets the changes to the "remote cache" on the server)

  4. I call the server method to define my single server with multiple roles, instead of multiple role method invocations for each role (passing the same server name each time)

  5. In the standard recipe, it is assumed that your database.yml is in the repository -- I don't keep it there. So after running cap deploy:update_code, I created a shared/config/database.yml which the deploy:db:symlink task links up for me.

Now to go share this on the google group.

Cheers.

blog comments powered by Disqus