This is article two of my Introduction to Rails series. You can find the previous article under the title Haml, SCSS and CoffeeScript with the Asset Pipeline.

Coming from a world of PHP, encountering a deployment process can be shocking. You mean I have to do something besides copy files to the server? That’s scary!

But a little while using Capistrano changes your perspective. Looking back on the world of PHP from this vantage point, I think copying files directly to the running directory is extremely scary! I think manually executing SQL to alter the database each time is barbaric! Most of all I think that not having an “undo” button is terrifying. Would you like to solve these problems? Read on.

Migrations

Instead of manually executed SQL, in Ruby on Rails database structure changes are described through migrations. Migrations are intended to be a database-independent way to list the tables, columns, indexes, keys and default values for your content. They have both up and down methods which contain the code necessary to create and undo the desired modifications, respectively. In cases where all commands are reversible (ie creating a table -> destroying the table), a single “change” method may be used instead.

You can run these changes in your local development environment with a simple rake db:migrate, but how do we host our application in production?

Shrink-Wrapped Solutions

When I joined 27 Volt Labs as co-founder my partner had been using Heroku as a simple one-step deployment tool. It is very little work to use, but it left us reliant on Heroku. We had no easy way to deploy to another service. I began looking for a more transparent solution and found a tutorial on deploying to a virtual private server.

Enter Capistrano

With the power of Capistrano one can easily deploy Ruby on Rails apps to any virtual private server. My host of choice is Linode (affiliate link). They have good performance for reasonable prices and their support response time has always been less than 20 minutes. Close inspection will show you that they host this blog and my web development company site [Update: I’ve closed shop on Aparadine with Carburetor taking all my time] as well, so my praise of them is not just empty words. I show it by giving them my business.

Capistrano isn’t likely to just work “out of the box” for you, but if you follow the RailsCasts about Capistrano it’s fairly easy (if a bit time consuming at first) to get set up. I suggest using a combination of Nginx, Unicorn and PostgreSQL but Apache, Phusion Passenger and MySQL are their respective alternatives for anyone interested in having a choice. If you’re having trouble and feeling unmotivated, read on. Capistrano provides some wonderful benefits and you’ll be happy you put in the effort.

Zero Downtime Deployment

When updating PHP-based sites the idea that users might encounter an error message between file transfers was just “part of the process”. Capistrano updates the entire application at once, eliminating any chance for such problems, by copying to a separate folder then switching the symlinks. Capistrano also allows you to hook your migration scripts into the deployment process to ensure that the database is altered at the proper time. This combination means you can now deploy with effectively zero downtime, assuming your deployment is successful. That’s a pretty big assumption. What if there are problems?

Back in PHP land, when there is an error after copying updates we quickly reverted to the previous commit and copy the stable files up to the production server. The same process as deployment, really. How could it get any easier? Well, there’s also the database changes we need to undo. Some quick SQL should solve that. It’ll take maybe a minute, two at most. That’s not long, is it?

With Capistrano, after an unsuccessful deployment we simply execute cap deploy:rollback. Since Capistrano keeps a copy of the last five (by default) deployments there is no repeat of the deploy process. Instead, the symlinks are changed and the database migrations are automatically rolled back to the previous deploy. The time depends on how long your migrations take, but generally it is a matter of seconds before the site is up again.

Now that you have a production site up and running, why don’t you have a look at the source. Pay particular attention to the JavaScript and CSS. They don’t look much like they did in development anymore, do they? As part of the deployment process Capistrano runs the asset concatenation and minification steps on your various scripts and stylesheets to help your application load faster and use less bandwidth.

Server Configuration

Capistrano allows for complex custom scripts to be executed. This is a bit beyond the intended use cases, but our Capistrano script allows us to bring up a new VPS from nearly scratch to full deployment with only a few commands. There are other tools specifically made for that kind of automation but for simple scenarios Capistrano is all you need.

That’s all for now but come back next Monday for the next article in this series. [Update: Models, Views, Controllers and Routing has been posted.]