The Buckblog

Update: as others have pointed out, this article may sound as if this approach is unique to Rails. It isn’t. I openly acknowledge that. The purpose of the article is to dispel the FUDdy claim that being a Ruby/Rails programmer somehow means you don’t know what it means to follow good deployment practices.

Picture this:

It’s late at night. You need to deploy an update to your production application ASAP. You type a (single!) command on your local development box which deploys your application to both of your application servers and restarts the fcgi processes for them. To your horror, though, you discover that the recent “fix” actually broke a few things! So, you type another (single!) command, and voila!, the update is rolled back and your app is running on the previous version again. You make the necessary corrections, type another (single!) command, and everything is beautiful.

Sound fun? Sound easy? Anyone want to take a guess at what environment we’re talking about?

Certainly not Java. Nor .NET. Heaven forbid it should be anything so “enterprisey”.

If you guessed Ruby on Rails, you’d be dead on. This is, in fact, the very way 37signals manages their application deployment.

How it works

37signals has developed (and will soon release) a “release manager” application, which they use in-house to do atomic, distributed deployment of their RoR applications. Both Basecamp and Backpack are deployed using this tool.

It allows you define a few simple configuration items in a yaml file, things like “hosts to deploy to”, “deployment path”, and even Ruby hooks to be executed at various points during the deployment.

This is then hooked up into the rakefiles for those applications, so they can do things like:

  rake deploy
  rake rollback

A deploy simply establishes an SSH connection to each box to deploy to, uploads a deployment script to that box, and executes it. This is done atomically, as well, so if the deploy fails on one box, it is automatically rolled back on all boxes. If the deploy succeeds, the fcgi’s are restarted and the application begins running on the new version.

Managing versions

Rolling back is possible because of the way the deployment works. Every production application has the following directory structure:

  [approot]
      +--- releases
      |       +--- 1234
      |       |      +--- app
      |       |      +--- doc
      |       |      +--- cache
      |       |      +--- log --> [approot]/shared/log
      |       |      +--- public
      |       |      +--- test
      |       +--- 1245
      |       +--- 1371
      |       +--- 1511
      |       ...
      |       +--- 2713
      +--- shared
      |       +--- log
      |       ...
      +--- current --> [approot]/releases/2713

In this lovely ascii diagram, you see the approot has two subdirectories (releases, and shared) and one symbolic link (current). The releases subdirectory contains one subdirectory for each release, named for the subversion version number of that release. The current symlink always points to the most recent release in that directory.

The web server is then configured so that the webroot of the application is [approot]/current/public.

When a deployment occurs, the latest release is checked out of the svn repository into the releases directory (of all of the production app servers) and the current symlink is updated. If all goes well on the other deployment servers, the fcgi processes are then restarted on all servers.

This makes rolling back to the previous version a snap. You just update the symlink, delete the bad version, and restart the fcgis.

Conclusion

As you can see, there need be nothing haphazard about application deployment in RoR. To be honest, I’ve used Java war files and ear files (alot) and hated them. They weren’t for me. I find the kind of agile deployment described in this article much more powerful, and simpler.

And, hey, it’s all written in Ruby. What’s not to like about that?