Add asset precompilation caching between deploys to Rails 3 & 4

[nthj]

We each know the pain of forgetting to check in one file at 3 am on a Tuesday night. We deploy to staging so we can email the client a progress report, only to bring down the app because of one oversight. We quickly rollback, but now the fun begins: we git push heroku master once again, only to wait, and wait, and wait, while rake assets:precompile generates an identical asset manifest to the one just generated not 10 minutes ago.

What if we could reliably speed up some of our deploys by a factor of 10? If we deploy ten times a week, and save 3 minutes per deploy, we've added 2 hours a month of productivity. How would we go about this? By attacking the largest bottleneck to deploying Rails apps on Heroku: precompiling assets.

Often our front-end code is unchanged, and we just want to tweak a rake task or fix a minor bug. This pull request side-steps the precompile task on such deploys by seamlessly loading in the precompiled assets from Heroku's cache directory.

We have been reliably using this technique on several production apps for about 8 months now, including at Huckberry.com, with about a dozen deploys a week. I've dropped junior developers into apps with this buildpack and it has just worked, no explanation required. And it's saved me many hours, my clients a lot of money, and made my Heroku experience much more enjoyable overall.

The one caveat I have run into are bundled assets being updated without a corresponding change to Gemfile.lock, in which case the diff statement doesn't catch the changes, and continues to use the cached assets. This is easily avoided by running bundle or just changing any file in app/assets, lib/assets or vendor/assets.

@pdsphil suggested I offer this as a pull request, and here we are. I'm looking forward to hearing your feedback, how we can improve this, and the possibility of helping to improve the Heroku deployment process overall.

Testing

To test this pull request, please run this command on your Rails 3 or 4 Heroku app:

heroku config:add BUILDPACK_URL=https://github.com/nthj/heroku-buildpack-ruby.git#precompile-optimizations

[fd]

+1

[dominic]

Having used this for a while, how often have you found this to be necessary? I'd normally expect a gem to update its version if it included new assets. Just the occasional edge case? Even including gems from source, it puts the commit hash in Gemfile.lock...

[nthj]

Only once, and I think that case may have been the reason I added the Gemfile.lock to the list of files to diff. Definitely not a recurring issue.

[nhance]

I wholeheartedly support this. YES PLEASE.

[jvdp]

+1, deploy times are getting a bit out of hand!

[boris]

👍 please

[vincentwoo]

👍

[bolek]

👍

[stereoscott]

I'm wondering how this commit: 06902d2 which stores/loads the public/assets folder in cache interacts could work with this pull request. It looks like if we rebase this pull request on the lastest version we could get the best of both words; using the default buildpack cache api while still checking for cached assets to skip the asset precompile when possible.