Easy Edge Rails Deployment

I have mentioned my affinity for edge rails several times. First, I showed you how I pimp my local setup. Next, I showed you how to really get edgy and lastly, I showed you that sometimes it bites back. Yeah, that still stings a bit. Anyway…this isn’t as dramatically cool as the first two or as stingy as the last one but it’s handy so here you go. Throw this in the bottom of your deploy.rb capistrano recipe and you’ll have easy peasy edge rails deployment.

set :rails_version, 7514 unless variables[:rails_version]

task :after_update_code, :roles => :app do
  rails_path    = "/var/www/apps/shared/rails"
  export_path   = "#{rails_path}/rev_#{rails_version}"
  symlink_path  = "#{release_path}/vendor/rails"
  
  # if revision does not exist then create it
  puts "Checking if rails revision #{rails_version} exists, exporting if not..."
  sudo "test -d #{export_path} || svn export http://dev.rubyonrails.org/svn/rails/trunk/ #{export_path}/ -r #{rails_version}" unless File.exist?(export_path)
  
  # create symlink in vendor folder to revision
  puts "Symlinking #{export_path} to #{symlink_path}..."
  sudo "ln -sf #{export_path} #{symlink_path}"
end

This makes a few assumptions that you might not want to assume, but I’ll leave that up to you to change. The basic gist is: make sure we have a copy of the rails version on the server and then create a symlink to it in your apps vendor directory. Now, if some great feature or bug fix comes into edge rails that you can’t live without, simply change the rails_version capistrano variable and the next time you deploy your app will automatically have a shiny new rails version symlinked into it’s vendor. This is handy if you have multiple apps on a server as they can share the same rails version which takes up less space. Yay!

Also, if you want to diss the rails_version set in your deploy file, you can pass the version you want in from the command line with something like this (off the top of my head could be different): cap -S rails_version=####.

Anyone else do something similar or have suggestions for improving this?

4 Comments

  1. Mike Clark wrote up a similar strategy that Rick Olson uses: see The Cadillac Approach towards the end of the article. I’ve been using that ever since and it works well.

    Your approach also looks good; perhaps a little simpler even.

  2. I would highly recommend using Piston to manage Rails edge and other fast-developing plugins (rspec etc) and including it in your own repository:

    • if you’re working in a team or using multiple computers you don’t have to continually check which version you should have in your own vendor/rails – this is major
    • rollback works
    • your app is self-contained and not dependent on other peoples’ repositories
  3. @Andy – Yep. I used Mikes for several months and decided that it could be done in a more simple fashion so I wrote this last week.

    @Ben – For some reason I haven’t really been interested in piston. We’ll see, maybe I’ll give it a looksey when I get some time.

  4. Hi John,

    I thought I’d mention this plugin I wrote in case you find it useful:

    http://geekblog.codora.com/2007/5/3/rails-plugin-cadillacedgedeploy

Sorry, comments are closed for this article to ease the burden of pruning spam.

About

Authored by John Nunemaker (Noo-neh-maker), a web developer and programmer who has fallen deeply in love with Ruby. More about John.

Syndication

Feed IconRailsTips Articles - An assortment of howto's and thoughts on Ruby and Rails.

Feed IconRails Quick Tips - Ruby and Rails related links.