Our Drupal 8 CI Workflow at UNB Libraries

In 2010, amid a usual morning of manual Drupal module updates, a colleague at UNB Libraries, Kassim Machioudi suggested:

Imagine if we only needed to change a version number in a metadata file to push all of these updates?

At the time, that idea seemed like a blue-sky dream. We were a small team, running many multisite and standalone instances of Drupal 5&6 across multiple servers. Drush make was not the stable solution it later became. Composer had not yet been released. For our team, module and core updates were painful - our update process consisted of extracting module and core tarballs on top of the existing live Drupal tree.

Most of our pain, however, wasn’t from the labour of doing the updates themselves - rather the problems that arose from doing the updates. When something went wrong, it went very wrong - we had no dev server, rollbacks were achieved only from nightly tape backups, and our local development environments were (at best) XAMP/Local Apache, and (usually) the live server itself.

Necessary Changes

Although version updates were a clear pain point, there were other pain points as well - most stemming from the the organic evolution of how we originally adopted and worked with Drupal. It wasn’t that our workflow was broken - rather that we really had not designed a workflow at all. We were highly motivated to change that. We needed a to improve.

For the sake of brevity, a detailed history of our tooling changes is not included in this main document. If you are interested in such things, the steps we took and tools we adopted in the following 8 years.


Great projects begin with defined goals. After a lengthy discussion, we proposed some blue-sky goals for the new workflow:




Developer Experience


The resultant workflow is documented in the Drupal 8 CI Workflow GitHub repository. Although currently a work in process, it outlines the details of how we work with Drupal 8, Travis and GitHub.

Post Tags:


comments powered by Disqus