Fred Durst continues rolling

Efficiency feels good.

To some extent, the joy of efficiency (or at least de-cluttering) is illusory. The pursuit of efficiencies may only make sense over long time scales. Making a decision whether to optimize is fraught.

Or is it? The common rule of thumb for duplication in computer programming is 3 duplicates. Anything you do twice, at the cost of labor, is something you should make faster the third time.

Things we've made faster

At the beginning of the year, the dev team committed to increasing efficiency, leading to the eventual ability to type a couple lines in a terminal prompt and have a 95% developed site with all the enterprise-grade Drupal fixins.

Here are some things we do really often that we've automated (or are working on):

How this works

Conceptually, a dev does something like:

compro site -b newclient

...has a new local site set up, rolls the repo with a stage/prod model, pushes it to bitbucket, and has a reasonable set of Drupal configurations for making a modern site. One command, giant head start.

When it comes time to make a new content type, we'd type:

compro ctf pressrelease

...and a new feature would appear in sites/all/modules/features containing a content type and view (with a page and block of teasers, both disabled by default). We could then ostensibly use drush's field commands in conjunction with drush's feature commands to roll an entire IA without looking at the site in a browser.

Once the content model is in place and there's sufficient real or dummy content, we theme it using our excellent in-house practices; entity view modes, minimal CSS, blockify, "extra fields", etc.

Then, for added efficiency, when it's time to roll the stage code onto production, we use:

git roll prod

This git alias looks like so:

[alias] roll = "!CURRENT=$(git rev-parse --abbrev-ref HEAD) && git checkout ${1} && git merge ${CURRENT} && git push origin ${1} && git checkout ${CURRENT} && git status && bash -c 'aplay ~/repos/compro_config/rollin.wav'"

In English, it checks out the production code, merges the staging code, pushes the merged code to the remote production repo, checks back out to staging, tells the user which branch it's on, and plays a clip of a Limp Bizkit song.

What's next

We'd like to automate our staging and production servers more, and leverage our CI tools to a greater extent. This will mesh nicely with our efficient local machines.

On the local development end, we're working to make removing local sites faster. It would be a dream to be able to spool up a site, test a single thing, and remove the site permanently in the span of a minute or two.

The theming and design processes have some real opportunities for streamlining. We haven't landed on the exact best approach, but are talking about it in the office constantly.


Efficiency feels good. In helping to write many of these streamlining pieces, I would literally say out loud "this feels good". If making systems more efficient is an illusory joy, I don't want to be dispelled of this illusion.

Looking for efficient Drupal development? Contact the experts

Drupal Security Guide free download