Drupal 8 Deployment Workflow

[Hinweis: Die Drupal Community feiert nun schon die 10. Version des Open Source CMS!]

Drupal in der Version 8 weilt nun schon seit fünf Monaten unter uns und hat einige Neuerungen mitgebracht. Besonders das neue Konfigurations-System ist hervorzuheben, denn dieses erleichtert das Deployment ungemein. Wir möchten einen Einblick in das Thema geben und kurz vorstellen, wie Drupal 8 Deployment nun bei uns gehandhabt wird.

“Mit Drupal 8 wird alles besser!” – Wie oft hat man diesen Satz vor dem Release von Drupal 8 gehört. Nun ist es bereits ein paar Jahre im Einsatz und ich denke die Community ist sich einig: Drupal 8 macht tatsächlich vieles besser als die Vorgänger-Version.

Am häufigsten wird dabei auf das neue Konfigurations-System verwiesen, welches komplett überarbeitet wurde, um das Thema Deployment mit Drupal deutlich zu vereinfachen.

“Früher war alles schlechter”

Wie war das noch gleich mit dem Deployment bei Drupal 7? Ach ja, genau: Drush, Features, Features Overrides, Update-Scripts und meist sehr viel Aufwand, oft sogar auch Ärger. Um nicht bei jedem Deployment einfach die Datenbank zu überschreiben (und somit alle Inhalte) hat man ein Modul dafür missbraucht, das ursprünglich gar nicht dafür gedacht war: die Rede ist vom Features Modul.

Dieses machte es möglich, bestimmte Konfigurationen aus der Datenbank in ein Modul zu importieren, welches man dann einfach per GIT Versionsverwaltung auf eine andere Umgebung übertragen hat. Dort musste man dann noch ein “Feature Revert” ausführen (meist per Jenkins) und dann wurde die Konfiguration in der Datenbank aktualisiert, ohne dass Inhalte dabei berührt wurden.

Das klingt nicht nur umständlich, das war es auch. Und es gab immer wieder Probleme dabei, seien es nicht exportierbare Konfigurationen oder Features, die sich nicht korrekt “reverten” ließen.

Drupal 8 Configuration Management Initiative

Das Problem erkannten natürlich die Macher von Drupal und starteten die Configuration Management Initiative (CMI), um Konfigurations-Management in Drupal 8 endlich zu vereinfachen. Somit wurde das Thema zur höchsten Priorität bei der Entwicklung der nächsten Drupal-Version. Durch ein klar strukturiertes Drupal Deployment wird Drupal zu einem CMS oder Application-Framework für professionelle Webprojekte.

Das neue Konfigurations-System bietet nun eine einheitliche Schnittstelle, um Konfiguration abzuspeichern. Primär wird die Konfiguration zwar immer noch in der Datenbank gespeichert, jedoch gibt es nun eine eingebaute Möglichkeit diese in YAML-Dateien zu exportieren. Möchte man nun beispielsweise die Konfiguration einer lokalen Drupal-Instanz auf eine Instanz auf einem Server deployen, überträgt man einfach die exportierten YAML-Dateien auf den Server und importiert diese.

Drupal stellt dabei durch sogenannte UUIDs (Universally Unique Identifier) sicher, dass immer genau die richtigen Konfigurationen aktualisiert bzw. überschrieben werden.

Jede Konfigurations-Einheit besitzt eine solche UUID, die auf allen Instanzen der Seite gleich ist. Das erlaubt eine fehlerfreie und einfache Synchronisation der Konfigurationen zwischen beliebig vielen Instanzen.

Es ist außerdem möglich, statt der gesamten Konfiguration der Seite nur einzelne Elemente zu exportieren und zu importieren, wie z.B. einen Inhaltstypen oder eine View.

Der Drupal 8 Deployment Workflow

Unser Workflow setzt sich hauptsächlich aus den folgenden vier Komponenten bzw. Tools zusammen:

• Git: für die Verwaltung von Code und YAML-Konfigurationsdateien
• Drush: für das eigentliche Deployment (Konfiguration importieren, Cache leeren, etc.)
• Composer: Verwaltung von Dependencies (Module, Libraries, Core)
• Jenkins: für die Automatisierung (Befehle auf den Servern ausführen, Automatisierte Tests etc.)

Das Zusammenspiel dieser Komponenten kann man in folgender Grafik erkennen:

Für jede Drupal-Seite, die wir entwickeln gibt es in der Regel drei Server-Umgebungen: einen Dev-Server für die interne Qualitätskontrolle, einen Stage-Server für die Abnahme durch den Kunden und natürlich den Live-Server. Entwickelt wird jeweils auf lokalen Instanzen.

Außerdem gibt es für jede Seite ein Git-Repository (Versionsverwaltung), in dem der Code und die Konfiguration gespeichert wird. Zu jeder Umgebung gibt es hier einen Branch (Entwicklungszweig), in dem der aktuelle Stand der jeweiligen Umgebung gespeichert ist. Um Drupal Updates kontinuierlich einzuspielen haben wir meist noch eine Update Instanz mit einem entsprechenden Branch.
Nehmen wir doch als Beispiel mal einen Inhaltstypen, der zu einer Seite hinzugefügt werden soll. Der Entwickler legt in seiner lokalen Drupal-Instanz (wir gehen davon aus, dass diese auf dem aktuellen Entwicklungs-Stand ist) den Inhaltstypen samt Feldern an.

(1) Danach exportiert er die komplette Seitenkonfiguration per Drush in sein Dateisystem.

(2) ie Änderungen “pusht” er in den Dev-Branch des zugehörigen Git-Repositories.

(3) Als nächstes soll die Änderung auf den Dev-Server deployed werden. Dazu reicht der Klick auf einen Button in unserem Jenkins. Dieser holt die Änderungen aus dem Git-Repository, importiert die Konfiguration in die Drupal-Seite und leert den Drupal-Cache.

(4) Wurde die Änderung intern auf dem Dev-Server getestet und abgenommen, kann der Stand auf den Stage-Server deployed werden zur Abnahme durch den Kunden. Das kann wieder der Jenkins komplett automatisiert übernehmen. Dazu “mergt” er den Dev-Branch in den Stage-Branch , übernimmt also alle Änderungen von Dev nach Stage.

(5) Nun folgt das gleiche Spiel wie zuvor auf dem Dev-Server: Jenkins holt die Änderungen aus Git und importiert diese.

(6,7) Genau im gleichen Schema würde dann auch das Deployment von Stage nach Live ablaufen.

Möchte man bestimmte Konfigurations-Variablen pro Umgebung überschreiben — z.B. wenn das Google Analytics Tracking nur auf dem Live-Server aktiviert sein soll — so kann man ohne weiteres in den entsprechenden settings.php Dateien machen.

Wie man sieht, ist der Deployment-Aufwand deutlich geringer als noch bei Drupal 7. Der Drupal 8 Deployment Workflow ist deutlich robuster und Bugs, die aus Deployment-Problemen resultieren, sehr viel unwahrscheinlicher. Dadurch, dass das Deployment nun kein so großer Unsicherheitsfaktor mehr ist, können auch Aufwandsschätzungen genauer getroffen werden, was sowohl uns als auch dem Kunden zugute kommt.

Wer ist eigentlich dieser Composer?

Composer ist eine Paketverwaltung für PHP-Projekte, die in Drupal 8 nun für die Verwaltung von Abhängigkeiten genutzt wird.
Drupal Core, Module und Libraries müssen dadurch nicht im GIT Repository gespeichert werden, sondern die benötigten Versionen können einfach in der composer.json Datei hinterlegt werden. Diese werden dann bei jedem Drupal Deployment von Jenkins installiert. Das macht es sehr einfach, den Core oder Module zu updaten oder neue Module hinzuzufügen.

Continuous Security im Drupal Deployment

Spätestens seit Drupalgeddon sollte klar sein, dass man das Thema Sicherheit bei Drupal-Projekten und generell im Web nicht aus den Augen lassen sollte. Deshalb gehört unserer Meinung nach das Einspielen von Sicherheitsupdates zum Entwicklungs-Workflow, Stichwort „Continuous Security“ im Drupal Deployment Prozess.

Wie bereits erwähnt erleichtert Composer das manuelle Updaten von Drupal Core oder Modulen. Allerdings ist das nicht die idealste Lösung, da dieser Schritt doch oft vergessen wird oder einfach zu spät kommt.

Es gibt allerdings eine Möglichkeit, diesen Prozess zu automatisieren und gleichzeitig in den eigenen Workflow zu integrieren: Drop Guard nennt sich ein von uns entwickelter Service, der sich nahtlos in den Workflow einfügt, indem er automatisch die aktuellsten Sicherheitsupdates im Git-Repository einspielt und auf Wunsch das Deployment anstößt. So ist sichergestellt, dass Updates schnell und unter Berücksichtigung der Qualitätssicherung automatisiert eingespielt werden.

Wie Drupal Deployment für Updates und andere Hotfixes funktioniert sehen Sie in der folgenden Grafik

Und was ist mit Content Deployment?

Drupal 8 trennt Inhalt und Konfiguration weiterhin strikt voneinander. Das bedeutet auch, dass alle Arten von Inhalt nicht über den oben genannten Workflow deployed werden können. Das betrifft unter anderem Menüeinträge, Custom Blöcke und natürlich jeglichen Inhalt wie normale Seiten und Artikel.

Um solche Inhalte zu deployen könnte man nun entweder ein eigenes Modul erstellen, welches die Inhalte beim Deployment anlegt (über hook_update_N) oder aber man nutzt eine Lösung wie das Deploy Modul, welches sich auf Content Staging spezialisiert hat. Alternative kann der Service Drupal Content Sync für Content Deployment oder Content Staging verwendet werden. Gerade zum Aufbau von Content Pools bietet dieser Service enorme Flexibilität und Geschwindigkeit in der Implementierung.

Zusammenfassung

Das “Features” Modul wird nicht mehr für das Deployment benötigt. Mit Drupal 8 lässt sich sehr einfach eine komplette Konfiguration exportieren und deployen und darüber x-Stufige Qualitätssicherungs-Prozesse aufbauen.

Der Kern des Drupal Deployment Workflows besteht dabei aus einer Kombination von Git, Drush, Jenkins und Composer um Anpassungen im Code und in der Konfiguration ohne manuelle Eingriffe über eine Deployment-Strecke zu transportieren. Inhalte müssen weiterhin auf anderem Wege deployed werden, wie dem Deploy Module oder Drupal Content Sync.