Delicious Drush desserts

I’m incredibly lazy, motivated, but lazy; and I hope you are too. This drives all of us to try and automate everything in life and makes Drupal developers look like rock stars of productivity while lounging in sleep pants with their morning coffee. What am I talking about? Drush, and specifically a new form of chain automation with drush that I’m going to be show-casing today. This is something I’ve been raving about the sandbox / dev build of on twitter for awhile now.

I’ve gotten Drush Recipes into an alpha state and ready for testing against a wider audience.

*gasp* What is Drush Recipes you might ask?

Drush Recipes is a packaging format for drush calls similar to Chef and the cookbook idea. You call a cookbook which is a series of calls and human-readable / understandable functionality is produced thanks to chain automation. Drush recipes brings this idea to drush by saying that a series of drush calls can also have human readable capability and I’d argue many of us out there are doing things like this right now:

drush @target dl views,ctools,panels | drush @target en views_ui –y | drush cc all | drush ecl | | | | |

You could do drush @target cook standard_build_routine –y which could tap a recipe (or series of recipes) and perform the same thing. The major difference is you can give this file to someone else, version it, or improve upon it and reuse it on your next project.

Other notable functionality of the plugin:

  • Supports JSON, YAML and XML based recipes
  • Supports simple argument based calls, more complex @target based calls (which can differ from the original target defined), references to other recipes, and conditional calls to other recipes (that prompt the user)
  • drush dwr which lets you author a new recipe via commandline and save to a file!
  • (my favorite!) drush @target1 ddt @target2 - which lets you produce a recipe that is effectively a “diff” of the commands required for target1 to become target2. This currently calculates modules to enable, disable, and download, variables that need deleted or changed to new values, roles to add / drop and permissions to add / drop between the sites.
  • Lazy load capability that will look local to .drush, in profiles, modules, themes, and sites/all/drecipes/ as to where recipes are
  • Plugs in with Profiler Builder and has plans for future GUI based integrations.
  • Future work on a webservice that can be used to sync up / find new recipes (similar idea to chef server)

The goal of drush recipes isn’t to replace your provisioning systems like Jenkins, Puppet, or Ansible; it’s to make the calls you make within them (as they relate directly to drupal) more simplified. Instead of writing all your drush calls into one of these spec’s and then not being able to share it with others, you can write a drush recipe that executes several commands as one.

Screencast (when don’t I do one; seriously?)

Here’s a video (it’s kinda long cause I talk through how each part works) showing all of these capabilities in their present state. notable jump points:

A few people have already jumped in the queue to offer feedback, patches and suggestions of potential recipes to add into the package so Let’s get cooking!