The Rails Asset Pipeline and Gulp Manifests
Tuesday, Feb 3, 2015
How we made the Rails Asset Pipeline use a Gulp generated Assets and Manifest throughout development, test and production.
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.
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
We will continue to generate the assets within the StyleGuide, however we will
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
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 27005750⁄4167520]).
- 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
This concept will be abstracted out to all of our tools, this blog can take advantage with a simple Gulpfile.js (gist).
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.
Need some help getting out of the asset pipeline?
Have an idea about how we could improve our approach?
Let me know below!