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):

• Configurations for Vagrant and Puphpet
• Module for contact info with tokens and blocks and fanciness
• Feature (to be used by a script soon) with a content type and basic views
• Site-specific custom module, with icon fonts and ready-to-go hooks for common tweaks
• Paragraph feature with fields for headings and templates for stuff
• Content feature with reasonable roles, filters, WYSIWYGS, Image styles, etc.
• An install profile that rolls it all together
• Bash utils to spool up local sites using drush and your choice of web server
• Shared configs for stuff like settings.php, .gitignore, .gitconfig, etc.
• Developer-specific themes without any dependencies

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

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