Rails deployment

One of the not (yet) addressed myths about Rails is that it is „hard to deploy roll updates on the server“. I keep hearing that over and over again. No, you can't just upload some .rb files on the server and magically run them. Even when deploying on mod_rails you have to touch something. But all these „annoyances“ have meant, that deployment of Rails applications, meaning: „pushing updates to the server(s), rolling back mistakes and maintaining the app and machine(s)“, is thanks to wonderful tools like Capistrano or Vlad actually an enjoyable experience, compared to hazy memories of „deploying“ a PHP „application“ couple of years back.

Yet, I've heard about one guy who „deploys“ by uploading files with Ruby code over FTPS. I guess he has all those .BAK1 and .BAK2 directories hanging in there. You, you are not that crazy. You, of course, use Git for versioning and collaborating on codebase, and deploy with Capistrano. You have the repository hosted on Github for easy access and lush GUI. (Check out Scott Chacon's tutorial if not.) Deployment? Deployment is the easy part. But you have friends. Friends who you work with on projects. Friends who have Windows™. Friends who „deploy“ by sending you messages over Skype™. Which works kinda reliably, but really isn't a paramount of convenience for either interested party.

So. You decide something must be done about it. You can write some Ruby scripts, don't you? It's true that the project you're in the middle of is on a very, very tight schedule. But you just cannot write cap deploy several times in an hour, just because your friend needs to update some CSS for MSIE6 as soon as possible.

Thus, Pushr is born. Pushr is a Sinatra application I had on my mind for couple of weeks or months maybe, definitely not long after I discovered you can setup post-receive hooks at Github very easily.

What is Pushr?

Pushr is an experiment. An alpha software. It's just one file. Most importantly, Pushr is an application running on the same machine as your Rails application, which deploys new version of the latter with Capistrano, whenever you push into a Github repository, automatically.

It does that, so you (or your designer friends) don't need Capistrano installed on their machines, they don't have to search fruitlessly for „how to set $HOME variable for Capistrano“, they don't need to know how to operate that freaky „MS-DOS“ prompt in their Windows, all that stuff. They can enjoy only the pain of working with Git on Windows. Of course, it is based on couple of assumptions, so let's review those:

• You have a Rails application properly set up for Capistrano deployment

• You have a deploy.rb configuration either in your repository or you know how to put it on the server

• You use SSH keys for authenticating you on the server and your deploy.rb is set up so

• You deploy via the remote_cache strategy (Capistrano keeps a copy of your app in shared/cached-copy in this case, doing just incremenetal updates on deploy)

• You have a deploy branch, which is what appears on the server, and reserve master for continual hacking and broken code

• You deploy from a Git repository hosted on Github, from the command-line, from the GUI client, whatever

• You can setup a post-receive URL in administration for you Github repo (See tutorial)

• You can install all neccessary gems on the server you are deploying to

• You can generate a SSH key on the server you are deploying to for the deployer user (you have to do it to pull code from Github anyway)

Step-by-step

What happens when you install Pushr and set-up the hook on Github, you'll ask? Well, it's quite obvious from the unordered list above, I guess. Everything is in place. Let's make it ordered.

1. You push something into a Github repository of your choice

2. Github calls a URL you specify as a post-receive hook. It finds a Pushr application there.

3. The request is authorized by a token you set in config.yml file and Github post-receive URL. (More on this later.)

4. Pushr switches into your shared/cached-copy directory and runs cap deploy:migrations there. (All the functionality on one line of Ruby? What is this? A scripting language?)

5. Your deployer user on the server then SSH-s to „itself“ (ie. something along the lines of ssh deployer@localhost), running Capistrano exactly the same way you do it on your own, local machine. Thus any peculiarities of your deploy, every symlinking in those Capistrano after hooks or running tests in before hooks are preserved and run just like you do it.

6. Capistrano's helpful verbose output is logged into a file deploy.log in Pushr directory, which looks like this:

Err, you think you have to tail -f this one? Are you some crazy sysadmin type or what? Pushr obviously sets deployer's Twitter status for true notifications du jour.

This way you can easily check on deploy results on the web, via Twitter's RSS or… get even more funky with Twitterrific!

A web interface

But that's still not all. Obviously, being a Sinatra application, Pushr has also a web interface. So, finally, you (or your… you get the picture) can literally „push a button“ to deploy the application:

Pushr tacitly does it's thing and presents you with Capistrano's output:

Now, what's the clear use-case for something like this? Definitely not some mission critical deployment you certainly have, working for some major medical institution, providing it with a Rails application giving personell up-to-date information about 10 000 patient's morning temperature, mind you! But not all applications are like this, do they? You may work for some low-profile establishment, providing local mom-and-dad grocery with a „websight“, right? That certainly isn't mission critical deployment, right?

Well, particulary when you work together on an application, constantly rolling updates to interface of said „websight“, making CSS tweaks, adding nicer rounded corners, adding that :order => 'position' you forgot again, stuff like that, that is where Pushr shines most. Nothing complicated. The request from Github or from your browser to Pushr is authorized only by a token you set in config.yml. It travels completely naked in the internets. It could be overheard! You could be compromised! You very probably won't be, but you could. If you're not afraid of this, strike one.

Two, as already said, you should have a special branch to deploy. You should hack in master (and do really crazy stuff in even other branch than master, for that matter). You should cherry-pick or merge into deploy branch only when everything's crisp.

Three, you should have tests for you application. (No, it's not enough you know you should have tests for your application. You really should have tests for your application. Because it's stupidly easy to do so in Rails. What? Test only assert_response :success if nothing else then.) And you really should run the tests in Capistrano's „before“ hooks. Even if those tests run for a while, you may not care, because you're just git push-ing and not staring on Capistrano's magic lines rolling in your Terminal.

I am using Pushr for a couple of days on two current projects, and I like it. Which tells nothing, of course, because a) I am the guy who wrote it, so you probably could call me „a little biased“, and b) I like technological nonsense. Most importantly, my colleagues, who're responsible for HTML and content, like it even more. Being able to update live Rails application just by pushing into Github repo seems to be a killer for them.

So if you'd like to give it a try, head over to it's Github page and install. It's very easy and it's all in the README. Definitely let me know in comments or an e-mail what you like and what you don't.

Update I

When your Github post-commit hooks stop working suddenly, do check them in the administration, because some of them may not survive recent transfer in Github application.

Update II

IMPORTANT! Pushr was heavily updated in the meantime, please read summary of changes.