without_scope

updated The approach to staging deployments with Vlad in this post is ridiculously dumb and complicated compared to this one.

Recently I've been reading about Vlad the Deployer. Like many in the Ruby community I was a bit put off by how they've chosen to promote Vlad. Anyone who knows me, knows there's nothing I like more than a bit of well placed arrogance and trash-talking but, I figured Capistrano was fine so why all the big talk against Cap?

Then I looked inside the beast...

At this point I don't even remember why but, I looked through the Capistrano source. Now, I feel pretty confident in my knowledge of Ruby and software architecture in general but, the Capistrano source gave me a migraine. Don't get me wrong, it's very well written code, it's just architected in a way that only the original author could really feel comfortable with it (yes, I'm putting this far nicer than I usually would because I have tremendous respect for Jamis Buck, Capistrano's author).

I can honestly follow the Rails routing code easier than I can Capistrano but that's another topic for another post.

Rule #n+1: Use the tools you have

Vlad makes great use of Rake. By using one of the best Ruby libraries out there, they got a lot for free. For example, instead of special casing the before_* and after_* tasks, they used Rake's dependencies and it's ability to extend a defined task.

They also use the ssh command instead of Net::SSH. Net::SSH is a really interesting piece of code, especially as one of the few examples of dependency injection (via Needle) in Ruby. However, there have been issues with using Net::SSH in Capistrano. I'm not going to question the value of having a native SSH implementation but, I'm not entirely sure why Capistrano should use it when it can accomplish it's goals by shelling out to the ssh cli.

A minor contribution - Deployment Targets (ex. Staging Environments)

Nothing speaks louder than a contribution and I have a small but valuable one. While talking with Chris Saylor we came to the conclusion that implementing support for staging environments in Vlad wouldn't be all that difficult. With a little bit of research, on Rake not Vlad, I came up with this.

This should go in RAILS_ROOT/Rakefile

    namespace "vlad" do
      desc "Setup the deploy target overrides"
      task :target

      rule "" do |task|
        if task.to_s.match(/vlad:target:([a-z_-]+)/i)
          override_path = File.join(RAILS_ROOT, 'config', "deploy.#{$1}.rb")
          Kernel.load override_path if File.exists? override_path
        end
      end
    end

Thank you Geoffrey Grosenbach for the Rake version of method_missing.

With this code in place you setup your deploy.rb with your production config, as usual. You can also setup as many deploy.*.rb files as you like. Off the top of my head, deploy.staging.rb and deploy.qa.rb may be useful. These files contain the settings that differ from your config.rb. You would then use Rake's ability to chain commands.

config/deploy.rb

set :application, "example"
set :domain,      "example.com"
set :deploy_to,   "/var/www/apps/#{application}"
set :repository,  "svn+ssh://svn.example.com/var/svn/#{application}/trunk"

config/deploy.staging.rb

set :domain,      "staging.example.com"

Deploying to your staging environment from scratch:

rake vlad:target:staging vlad:setup vlad:update vlad:migrate vlad:start

Simple, easy to understand how it works and it's all standard Rake, no real Vlad magic involved.