Getting to grips with automated deployment in Drupal 8

Many agencies have a well defined way of deploying updates to their customers’ Drupal 7 sites. Deeson is no exception to that rule. With the massive changes in Drupal 8, we figured this process would need to be looked at again. Our recent Notes Day, a dedicated day for improving how we work as an agency, was the perfect opportunity to do so.

Before we start

To get a good understanding of what we were trying to (re)build, here’s a quick run-down of a common Drupal 7 set-up:

1. We use Drush make to download and patch everything that isn’t custom.
2. Custom modules, themes and libraries are version controlled, while contributed code isn’t. This keeps the repository small.
3. Drupal core is the exception: It is also version controlled so we can easily track changes to .htaccess files and the like.
4. Configuration is stored using the Features module. Our features are version controlled as custom modules.
5. The .gitignore file is configured for all of the above.
6. We use the Master module to enable/disable modules per environment

Composer all the things! Or not?

Our first goal was to move away from Drush make and use what everyone else is using: Composer. Drupal 8 uses it to build its own dependencies and has recently opened a Composer repository of its own. Keep in mind this is still in alpha.

But here we already ran into a major issue. Packagist, the main Composer repository, already lists Drupal as a package. So if we want to grab the “drupal/drupal” package or the “drupal/core” package, Composer grabs it from Packagist instead of the official Drupal repository. This is due to Packagist trumping all other repositories.

You can, however, disable Packagist as a repository. But then you disable it for all required packages. Meaning if your site also needs a library from Packagist, you’re out of luck. There is no way to disable Packagist for just one package.

To add insult to injury, there’s also another community-built repository at https://packagist.drupal-composer.org/ and a “drupal/drupal” on Packagist which claims to replace “drupal/core”, even though the latter is the one you ideally want to use.

Conclusion: We have sources all over the web claiming to host Drupal for Composer, hardly any of them play together nicely and with the official repository in alpha it doesn’t seem like the situation will improve any time soon.

So what should we use?

If you are dead-set on using Composer, have a look at the drupal-project repository on Github by Bojan Živanović. He knows a ton about Composer and managed to get it to work with Drupal 8.

As you can tell by looking at his repository, there is a lot more needed than just a composer.json file to get it to work. We found this to be a dealbreaker as we would be relying on Bojan’s expertise blindly without knowing half of what’s actually going on within our build process.

If you share our inhibitions and want to see how things evolve first, we do have good news! Drush make still works beautifully so you can port that workflow straight to Drupal 8 with little to no alterations. We decided to go with this option for the time being.

Next up: Configuration management

With Drupal 8 came the configuration management initiative (CMI). This basically replaces the Drupal 7 Strongarm module by allowing you to export any configuration as a YAML file.

We figured we’d use this instead of Features because it’s always good to cut out the middle man, right? Wrong. It turns out you can’t simply ship some YAML file updates to your server and expect the site to “revert” to the new state like Features used to do in Drupal 7.

If you want to update your configuration, you’ll need to both export the new YAML file and write an update hook that details exactly what’s changed. This is obviously quite cumbersome.

Furthermore, you can’t enable a module that has certain configuration if it already exists in the website. Seeing as features are modules that do exactly that, the Features team had to swap out the configuration manager in Drupal 8 in order to make this work. Sounds dirty, but at least it works.

Conclusion: We gladly accept the presence of the middle man known as Features. We would have loved to use “just” Drupal core for this. Sadly it seems CMI fixed a lot of things, but not deployment workflows.

Wow, so what about the Master module?

So far we’ve scored 0 out of 2. The silver lining being that we can keep using the old workflow just fine. So with high hopes we took a look at the Drupal 8 version of the Master module. At least, we tried to - we couldn’t because there is no release for Drupal 8.

According to the module maintainer “derhasi”, there are no plans to port Master to Drupal 8. Because this news has made us all really sad pandas, we may spend one of our developer lounges cooking up a successor because let’s face it: Nobody likes to score 0 out of 3.

In conclusion

To sum things up: It’s perfectly safe to use your old workflow for the time being. We’ve tried and tested it and it all works fine. Except Master. Master is really, really dead right now.

However, we don’t want to advocate stagnation so we will keep a close eye on future developments regarding this subject.

It would also be great to hear from the people behind what we just investigated: Larry Garfield (Crell) for CMI or Bojan Živanović (bojanz) for Composer. Let’s see if we can get them to weigh in on the matter and get a discussion going.