Deploying Production Assets with Bedrock and Roots

bedrock
1

I wrote a longish blog post about this here, but the short version is that the way the Roots starter theme handles assets doesn’t work with Bedrock out of the box.

Bedrock uses Git for deploys, but some of the necessary files are .gitignore’d in Roots:

  • Minified assets generated by Grunt
  • assets/css/main.min.css
  • assets/js/scripts.min.js
  • assets/js/vendor/modernizr.min.js
  • The generated asset manifest file used by scripts.php
  • assets/manifest.json
  • The Glyphicons font files used by Bootstrap
  • assets/vendor/bootstrap/fonts/glyphicons-halflings-regular.eot
  • assets/vendor/bootstrap/fonts/glyphicons-halflings-regular.woff
  • assets/vendor/bootstrap/fonts/glyphicons-halflings-regular.ttf
  • assets/vendor/bootstrap/fonts/glyphicons-halflings-regular.svg
  • jQuery, which gets used if the Google CDN can’t be reached
  • assets/vendor/jquery/dist/jquery.min.js

I’ve found three different ways people are dealing with this:

  1. Remove the files from .gitignore and commit them.
  2. Build the files on production.
  3. Build the files locally and copy them to production.

What approach do you prefer? Is anyone using another approach that I haven’t seen?

I’m adding the files to Git right now, but I’m leaning toward building them in production. Getting away from Git-based deploys completely is another option, but I’m not sure it would be worth the effort.

1 Like
2

They’re in the Roots .gitignore but that has little to do with using Roots as your theme when you’re deploying with Bedrock. That .gitignore is the Roots theme’s file and since Roots isn’t meant to be used as a child theme you can safely remove it and the .git/ directory from your theme. And you probably should.

Nice post btw.

3

Options 2 and 3 are probably the better two to decide between. And I’d lean towards going with #3 if Capistrano had better support for it by default.

Great post as well! Very thorough.

4

What’s wrong with #1?

5

The built assets shouldn’t be committed to your repo

6

That’s what I’ve gathered, but why not? If a new dev clones the repo to make changes they will end up re-building the assets anyway…

7

Exactly? That’s the best way to guarantee consistency since they go through the same process as you did. Obviously it should produce the same output but who knows.

To me, production assets are a build artifact. Anything that’s the output of a build process shouldn’t be committed to source control. It also prevents anyone from EVER just doing some quick temporary change to a production asset and not reflecting it in the actual source files.

8

I like the simplicity of just removing the .gitignore file from the Roots directory, but it does add a lot of extra files into version control.

My Roots directory has 69 files under version control now, removing the .gitignore from Roots adds 376 more. Most of these are the uncompiled bits of Bootstrap, jQuery, and Modernizer, plus quite a few documentation files. Bower pulls in a lot of unnecessary crap, since it just copies the entire repository for each library.

Hopefully in the next couple of weeks I’ll get around to writing posts on the other two options that don’t require adding the built assets into Git.