This post originated from an RSS feed registered with Ruby Buzz by Jamis Buck. Original Post: Application Deployment with Rails Feed Title: the buckblogs here Feed URL: http://weblog.jamisbuck.org/blog.cgi/programming/index.rss Feed Description: Jamis Buck's corner of the blogging universe. Mostly about ruby, but includes ramblings on a variety of topics. Latest Ruby Buzz Posts Latest Ruby Buzz Posts by Jamis Buck Latest Posts From the buckblogs here

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?