Getting started

First of you need to install the Vlad gem: $ sudo gem install vlad

In its current version (1.3.2) Vlads default options are deploying from a SVN repository to a cluster of mongrels, which is not exactly what we are after. We need to configure it to use Git and Passenger, so switch to your Rails project and add the following lines to the end of the Rakefile:

begin
  require 'vlad'
  Vlad.load :app => :passenger, :scm => :git
rescue LoadError
  puts 'Could not load Vlad'
end

Run $ rake -T vlad to verify that Rake and Vlad know each other.

Now it’s time to set up your deployment configuration. Configuring Vlad is very similar to Capistrano, most of the variables are the same, so that you can easily migrate if you where using Capistrano before. Here is a simple configuration file including a deployment recipe which I’m currently using:

set :user, "myuser"
set :domain, "my.domain.com"
set :application, "myapp"
set :deploy_to, "/var/www/#{application}"
set :repository, "git@github.com:#{user}/#{application}.git"
 
namespace :vlad do
  desc "Symlinks the configuration files"
  remote_task :symlink_config, :roles => :web do
    %w(application.yml database.yml).each do |file|
      run "ln -s #{shared_path}/config/#{file} #{current_path}/config/#{file}"
    end
  end
 
  desc "Full deployment cycle: Update, migrate, restart, cleanup"
  remote_task :deploy, :roles => :app do
    Rake::Task['vlad:update'].invoke
    Rake::Task['vlad:symlink_config'].invoke
    Rake::Task['vlad:migrate'].invoke
    Rake::Task['vlad:start_app'].invoke
    Rake::Task['vlad:cleanup'].invoke
  end
end

Gotchas

It took me a while to get everything up and running because I encountered permission problems while trying to access the application repository from my deployment server. If you are running $ rake vlad:update and experience Git errors like fetch-pack from '...' failed, turn to Jordan Elvers blog post about it – he explains how you can solve this by setting up SSH agent forwarding.

Advancing

Need to go further and setup a multistage deployment environment? Check out this post on the Engine Yard blog, they solved this problem already.

Exception Driven Development

No code is faster than no code – was für die Applikation gilt, lässt sich auch 1A auf Tests und Spezifikationen anwenden, daher hier Credo Nr. 1:

No test is faster than no test.

Damit erübrigen sich auch die ganzen Diskussionen um langsame Tests durch zu viele Fixtures oder das ganze Mock/Stub-Geraffel. Test less!

Wer von sich überzeugt ist, deployed ohne Testsuite – no coverage is the new black. Ich weiss, das klingt fremd und sehr wagemutig – aber kein Ding, denn du musst diesen Weg nicht alleine gehen. Es gibt Hilfe, denn selbst die Besten machen Fehler – Exception Notifier to the rescue.

Spätestens wenn eine Anwendung in Produktion läuft, zahlen sich die Vorteile von EDD dank des Plugins voll aus: Du musst nicht mehr nach den Fehlern suchen, sie kommen zu dir – per E-Mail! Jede geworfene Exception erreicht dich per E-Mail und liefert dir detaillierte Informationen über den Fehler, so dass du ganz bequem das Error-Backlog aus deinem Postfach heraus abarbeiten kannst.

Klingt heftig und dabei ist hier noch nicht einmal Schluß – treiben wir es auf die Spitze…

Soon to be released: Mister EDD

Um euch allen den Einstieg in EDD zu erleichtern, schnüre ich aktuell ein feines Rails-Plugin zusammen, dass euch am Anfang etwas unter die Arme greift und Rails-like sehr opinionated zur Sache geht: Bei der Installation wird zunächst als Dependency das Exception Notifier Plugin installiert (sofern du es nach dem letzten Abschnitt nicht schon selbst eingebunden hast).

Next Step: Test- und Spec-Verzeichnisse werden gelöscht, wenn schon, denn schon… you cant be any geek off the street, gotta be handy with the steel if you know what I mean, earn your keep!

Zu guter letzt werden noch die Rails- und RSpec-Generatoren überschrieben, so dass in Zukunft keine störenden Tests mehr generiert werden  (danke für den Hinweis, Jan).

Denkt mal drüber nach