The Rails Asset Pipeline and Gulp Manifests

By dirkkelly

Tuesday, Feb 3, 2015

How we made the Rails Asset Pipeline use a Gulp generated Assets and Manifest throughout development, test and production.

Problem

Users are visiting our new dynamic tools for matching with participants, for the most part they’re loving it, for the sad few though they’re unable to see any results without hard refreshing.

This issued arose from leaving the native Rails 4.2.0, a move which has resulted in much faster development, at the cost of the producton reliability.

The StyleGuide is one of the tools we’re using to standardize the technology amongst all of our web services, it’s also the most innovative tool we’re building and is sitting on the absolute edge of our technology stack.

It’s important that we make changes now to our process to ensure the continued success of our tools.

Plan

We need to use fingerprinted assets to ensure that a web browser is forced to download the latest itteration of the StyleGuide asset. We want to avoid the Asset Pipeline as much as possible, without leaving the standard Rails 4.2.0 api, namely
stylesheet_link_tag 'interexchange.css'

We will continue to generate the assets within the StyleGuide, however we will generate a manifest-md5hash.json file, this will be compatible with Sprockets 3.0.0.beta.6. The added advantage of this is that the published assets we build in StyleGuide will be the same files sent to the AWS and used throughout the rest of the deployment process, Continuous Integration, User Acceptance Testing, Production.

How it went

Test Results

Well the tests have finally gone green, seems like we we’ve kicked this one out of the park.

  • Gulp compiles our assets (instantaneously) and builds an asset manifest
  • The Application copies the updated manifest from StyleGuide
  • We force Rails to refresh the manifest on each request in development (thanks [SO 270057504167520]).
  • When we’re happy we commit in both projects
  • Push the app to CI, sync the StyleGuide with S3 (we use [Transit Sync] right now)
  • The same SHA on Continuous Integration, Staging and Production will use the same version of the assets
  • Older assets aren’t immediately destroyed (we’ll have a retention policy), so will still work in emails etc

Gulpfile.js Overview

The same command gulp serve in Application and StyleGuide will keep the asset manifest in sync, edit StyleGuide, see the resulting code is recompiled and merely re-referenced.

This concept will be abstracted out to all of our tools, this blog can take advantage with a simple Gulpfile.js (gist).

Gulpfile.js Overview

Note: The above links to a gist with a snapshot of our configuration.
If we make changes in the future I hope to come back and update this.
If these seem out of date, leave a comment and we will update it.

It’s Working!!!

It's Working

Need some help getting out of the asset pipeline?
Have an idea about how we could improve our approach?
Let me know below!