Skip to content
Our Drupal 8 CI Workflow : A detailed document outlining our local-to-prod Drupal 8 CI Process/Workflow at @unb-libraries. Intended for others to contribute and learn. We deploy Drupal containers on Kubernetes, test instances on Travis, and develop locally fast and simply by leveraging Robo.
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
img
testing
BaseImage.md
CargoDock.md
CommitFallout.md
Drupalista.md
Jenkins.md
Kubernetes.md
LeanRepository.md
LocalDevelopment.md
MeanderingHistoryOfTools.md
README.md
Testing.md
Travis.md

README.md

Our Drupal 8 CI Workflow

Small Team, Big Tools

Drupal 8 CI Workflow

Introduction

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 far-off 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 is outlined in the Meandering History of Tools.

Goals

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

General

  • MIT Licensed, open lean instance repositories. Anyone can deploy and bring up our applications.
  • Track upstream libraries in metadata only, not in lean repositories.
  • Three layers of instance testing : Unit, Behat and Visual Regression Tests.

Code

  • Deployment environments defined by branches - beginning with dev and production.
  • Synchronized branches - commits rebased upstream through environments.

Deployment

  • Instances tested automatically prior to deployment.
  • Secrets stored in orchestration layer.

Developer Experience

  • Local development instances that approach parity with production instances.
  • Minimal local development tool installation.
  • A developer workflow that requires as little knowledge of Docker / underlying tools as possible.
  • Lightning fast local development kickstarts.

The Components

In-depth documents focused on each each component can be found on the following pages:

Workflow Topics

Contributors

You can’t perform that action at this time.