jeff gardner.

Cached Assets on Heroku with heroku_san

I’ve been working a lot recently on finishing up a client project. SalesVote is basically a daily deals site with a fun twist—it adds game theory, and the chance to make a little money yourself into the mix. It’s been a great project with a great client and now that it’s finally drawing close to a full public launch I’ve been cleaning up a few things and trying to streamline as much of the app as I can. Usually I try to add caching while building an application but this project has been such a whirlwind of front and back end code (I’m writing the app alone) that I just haven’t had a chance to get all the caching I would like into place yet.

One thing that has been bothering me recently though is the number of js and css files that I was loading. Rails does such a good job of automatically caching those resources that you quickly forget what it’s like to have to combine files manually. Unfortunately, on Heroku the read-only file-system makes this auto-caching impossible. A short piece of googling later though gave me the parts that I needed to reinstate dead simple, automatic rails static asset caching.

The shoulders of giants

This article from Trevor Turk was exactly the type of thing that I wanted to setup. A quick rake task that would cache the assets, push all that to my github repository for the code, deploy the newest code to heroku and then notify hoptoad of the deploy. Unfortunately, Trevor’s code wasn’t drop in an go, I am using a gem called heroku_san to help manage different environments of my app on heroku (I have a staging environment and a production environment—essentially two different applications on heroku) and heroku_san uses a “deploy” task to do it’s deploys. I would have to come up with another way to actually call the deploy.

Thoughtful gems

At first I thought that perhaps I’d just dump the heroku_san gem and write the deploy tasks myself, but that would require writing a different task for each environment I wanted to deploy and since I’m super lazy I figured that there must be an easier way. I took a look at the readme for the heroku_san gem and; lo and behold, there are two simple hooks, before_deploy and after_deploy, that I could use to tie custom rake jobs into the deploy sequence that heroku_san uses. Way to go on making it simple to extend your gem guys!

Nitty gritty

The first thing that you’ll need to do is install heroku_san (generally by just adding it to your Gemfile and running bundle install) and follow their instructions for setting up your apps different environments.

From this point you should be able to deploy your app to production with rake production deploy. Got this far? Good. Next you’ll need to the following three rake files in the /lib/tasks directory.

This is the rake task that heroku_san will look for just before it does that actual deploy of code to heroku.

This is Trevor Turk’s rake task to cache js and css files and commit those files into the repository.

This is the rake task that runs after heroku_san deploys to heroku and I’m using this to make sure we notify hoptoad of the deploy.

It’s as simple as that. Now just run your normal rake production deploy (which I have aliased to rpd for speed) and you’ll see the extra terminal output as your app gets it’s stylesheets and javascripts cached, heroku_san deploys to heroku for you and then hoptoad gets notified of your deploy. The coolest thing about these hooks is that you can now call any kind of task you would like and heroku_san will run it before or after it deploys your code. Very simple, very clean: I like.


Tagged: Trevor Turk, heroku, deploy, web apps, heroku_san, asset caching, and ruby on rails 3
13 April 2011

blog comments powered by Disqus