Let’s .make fun with Drush for Drupal

This post is a summary of a talk I gave at DrupalCamp London 2016. It contains a high volume of bad words like: Drush, make, deployment, environment, patch. If you often find yourself using most (or even ALL) of these words in the same day, then this post is for you! And if you don’t, but you are a Drupal developer, then this post is DEFINITELY for you too as, soon or later, you will start using them. So why not be prepared?

What’s it for?

You will be amazed how many Drupal developers still download Drupal modules and themes manually from Drupal.org. Or have patches files and folders spread around the whole Drupal codebase (if they are wise enough to add them to the repository)!

Have you ever wondered if there is a better way of taking care of your Drupal codebase? A better workflow? An approach to keep everything organized, clean and documented?

For those who already know Drush it’s worth having a look at the `drush make` command.

drush make myfile.make my-docroot

What is Drush Make?

Make is a Drush extension able to create a ready-to-use Drupal site from a simple text file (.make) listing rules (source types, paths, destination names) and dependencies. You can look it as an improved, centralized and documentable version of `drush pm-download`.

But wait, there is much more.

What Drush Make will do for you:

• Download projects and libraries
• Organise downloaded files
• Patch projects and libraries

What Drush Make won’t do for you:

• Install your website (but it can prepare the codebase for installation)
• Know about (multi-)sites on your website (but you do and you can make it do it!)
• Take care of projects dependencies (by itself, but its recursion feature could help)
• Run pre/post execution scripts (like composer does)

What the .make file looks like

The .make file is a plain text file using YAML or .info INI syntax. You can manually create one from scratch or generate one from an existing site.

It’s a list of projects (modules, profiles, themes) and libraries (javascript plugin, PHP libraries, etc.) you need to properly run your website.

Each project/library can have multiple options depending on the version you want, the source location for the files, the destination directory on your codebase, etc. See a full list of Project Options and Library Options.

Make also has these additional functions:

• Recursion (list your projects/libraries dependencies within your module’s .make file, they will then be downloaded automatically)
• Includes / Overrides (split your list into multiple files, and merge them on execution)
• Patching (centralized, documentable and bullet-proof place to list your patches)

Ok. All very interesting. But seriously, what’s the everyday benefit of using Drush Make?

.make your workflow

At Manifesto we use the Dev -> Stage -> Prod workflow, with automatic tests in between.

Our projects have up to four .make files:

• base.make for all the common modules and libraries
• dev.make listing the modules needed only on the Dev environment
• prod.make listing Production only requirements
• test.make with modules and libraries needed for the test suites.

On building the codebase, we select base.make file and include the rest according to the current environment.

The repository then contains only our Vagrant/Docker file, the .make files and, through this .gitignore skeleton, only our custom modules are added to the repo.

Sometimes we have to create a temporary mini-site or a campaign, which will stay on our codebase for a certain period and has to be removed right after.

Ever been in the situation where you don’t know if a module was being used by your entire website or only for that campaign? List your requirements into my-campaign.make and you don’t have to worry about it!

Custom .htaccess

Drupal motto is: don’t hack the core! But there are some files you are allowed to change, e.g. .htaccess or robots.txt, and you are likely to see your changes reverted as soon as you update the core.

At Manifesto we have been in this situation, and of course Drush Make helped us.

On our prod.make we added a local patch (yes, patches can be either from a URL or relative to your .make file) to the Drupal core in order to apply to the .htaccess our custom rewrite rules.

Here you can find the examples used in my presentation Let’s .make fun at DrupalCamp London 2016, plus additional ones inside the ‘other’ directory.

I hope you will find some of them useful enough to add Drush Make to your own workflow.