Direkt zum Inhalt

Drupal Deployment

Konfigurationen lassen sich dank des .yaml Formats der Konfigurationsdateien besser lesen als in Drupal 7
05.03.2018 - 11:03 von Sebastian Gurlt

Seit unserem Blogpost von Juni 2013 hat sich rund um Drupal so einiges geändert und so auch um das Drupal Deployment. Daher haben wir diesen Beitrag überarbeitet und für Sie auf den neuesten Stand gebracht. Viel Spaß beim Lesen!

 

Lange wurde uns versprochen, dass mit Drupal 8 alles besser wird. Alles ist sicherlich noch nicht perfekt, allerdings gab es mit Drupal 8 im Deploymentbereich eine große Änderung, die keiner ignorieren kann: das Configuration Management System.

 

Configuration Management System

Das Configuration Managment System ist Teil des Drupal 8 Cores und wurde dafür entwickelt, Konfigurationen von einem System zu exportieren und diese auf einem anderen System wieder zu importieren. Wofür in Drupal 7 noch Features verwendet wurden, gibt es in Drupal 8 nun das Configuration Management und Features können nun endlich dafür verwendet werden, wofür diese ursprünglich entwickelt wurden.

 

Features: Kurzer Exkurs in die Geschichte von Drupal

Features wurden „damals“ dafür entwickelt, einzelne Komponenten einer Drupal Seite exportierbar zu machen und diese dann auf einer weiteren Seite erneut verwenden zu können. Es war nie die Intention von Mike Potter (Maintainer von Features), komplette Drupalseiten mit der Hilfe von Features von einem System auf ein weiteres zu schieben.

Mit Drupal 8 funktioniert dies nun besser als je zuvor und es können einzelne Komponenten, wie z.B. eine Media Entity Type, in ein Feature exportiert und dieses immer wieder auf weiteren Seiten verwendet werden. #saveTimeUseFeatures

 

Konfigurationen lassen sich sehr einfach mit der Hilfe von Drush exportieren und ebenso auch wieder importieren:

  • Drush config-export
  • Drush config-import

Im Gegensatz zu Drupal 7 werden in Drupal 8 mit einem config export/import immer sämtliche Konfigurationen eines Systems exportiert bzw. importiert. Dies stellt sicher, dass nicht aus Versehen Konfigurationen vergessen werden können und immer alles auf das nächste System übertragen werden kann.

Es kommt allerdings auch vor, dass manche Einstellungen nicht übertragen werden sollen. Ein gutes Beispiel ist die konfigurierten Seiten-eMail-Adresse. Diese soll oftmals auf dem Live System konfiguriert werden können und dann nicht bei jedem Drupal Deployment überschrieben werden. Um dies zu ermöglichen, können die Modul Config Ignore oder Config Split verwendet werden.

Zusätzlich zum vereinfachten Exportieren/Importieren ist es nun möglich, Drupalseiten komplett „from Scratch“ auf existierenden Konfigurationen neu zu installieren. Die Sicherstellung eines reibungslosen Installationsprozesses ermöglicht es uns, neue Entwickler zu laufenden Projekten hinzuzuziehen, ohne diesen eine Datenbank und Files bereitstellen zu müssen.

 

Configuration Management System und Features Branches

Auch in Drupal 8 wird weiterhin in Features Branches entwickelt. Dies ermöglicht uns, einzelne Komponenten losgelöst von anderen Entwicklungsobjekten zu entwickeln und diese unseren Kunden so schneller bereitzustellen.

In Drupal 7 kam es immer mal wieder zu Problemen beim Zusammenführen von mehreren Entwicklungen, da der Aufbau des Codes in Features oftmals zu Konflikten geführt hat. Beispiel:

  • Entwickler A entscheidet, dass Konfiguration X in Feature 1 gehört
  • Entwickler B entscheidet, dass Konfiguration X in Feature 2 gehört

Beim Zusammenführen stellt Drupal fest, dass eine Konfigurationen doppelt vorhanden ist und es kommt zum Fehler. Nun können sich die beiden Entwickler darüber streiten, wer schuld ist und es geht wertvolle Zeit verloren.

Auch dieses Problem wurde dank des Configuration Managements aus der Welt geschafft. Dadurch, dass immer sämtliche Konfigurationen exportiert werden und diese auch immer automatisch festgelegte Namen erhalten, ist es nun nicht mehr die Aufgabe der Entwickler, eine Konfiguration zu benennen, sondern dies wird durch Drupal festgelegt.

Auch lassen sich Konfigurationen dank des .yaml Formats der Konfigurationsdateien nun einiges besser lesen als zuvor in Drupal 7.

Beispiel „system.site.yml“ – Drupal 8

 

Dank des .yaml Formats der Konfigurationsdateien lassen sich diese nun leichter lesen als zuvor in Drupal 7.

 

 Jenkins und Pipeline Jobs

Nicht nur im Drupal Deployment hat sich einiges getan, sondern auch in dem von uns genutzten Deployment-Tool Jenkins. Seit einiger Zeit ist es mit diesem möglich, sogenannte Pipelines Jobs zu erstellen. Ein Pipelines Job stückelt ein Deployment in mehrere Steps, dies könnte z.B. so aussehen:

  1. Prepare Deployment
    1. Run a backup
    2. Set site into maintenance mode
  2. Update Code
    1. Merge previous Branch
    2. Pull changes from Git
    3. Run composer install
  3. Update Drupal
    1. Run database updates
    2. Run configuration import
  4. Cleanup
    1. Clear the Drupal cache
    2. Disable maintenance mode
  5. Notify
    1. Send a message to Slack

Doch was ist das Besondere daran, dies war doch zuvor auch schon möglich mit einfachen Jenkinsjobs? Der Unterschied zu einfachen Jenkinsjobs ist, dass der Pipeline-Ablauf einmal durch eine Jenkins Library definiert wird und dann zukünftig der Deploymentprozess in allen Projekten den gleichen Ablauf hat, ohne die Jobs jedes Mal aufs neue konfigurieren zu müssen.

Sobald die Library einmal eingerichtet wurde, muss lediglich zu jedem Projekt eine Jenkins Konfigurationsdatei (Jenkinsfile) hinzugefügt werden. Dies ermöglicht projektspezifische Einstellungen, wie z.B. in welchen Slack Channel Nachrichten geschickt werden soll.

Beim Einrichten des Pipeline Projekts in Jenkins ist es dann möglich, die Git URL anzugeben. Jenkins scannt im Anschluss alle Branches in dem Git Repository nach dem Jenkinsfile. Für alle Branches, in denen ein Jenkinsfile vorhanden ist, wird dann automatisch ein neuer Pipeline Job bereitgestellt. Auf diesem Weg wird der Deploymentprozess für alle Projekte vereinheitlicht und es muss bei Problemen nicht immer erst geprüft werden, wie denn überhaupt für dieses eine Projekt das Drupal Deployment jetzt genau funktioniert.

Auch bei der Fehlersuche helfen die Pipeline Jobs. Gab es in dem oben genannten Beispiel ein Problem beim Step „Update Drupal“, zeigt Jenkins in seinem Interface an, dass es an diesem Punkt zum Abbruch kam und was diesen ausgelöst hat.

Hier ein Beispiel aus einem unserer aktuellen Projekte:

Pipeline Jobs helfen bei der Fehlersuche im Drupal Deployment

 

Default Content und Drupal Deployment

Dass Inhalte prinzipiell nicht in ein Deployment gehören, ist allseits bekannt. Kein Kunde freut sich, wenn die von ihm erstellten Inhalte durch die Testinhalte von einem Entwickler überschrieben werden.

Oftmals ist es aber gewünscht, dass z.B. einige Standardbegriffe in einen Taxonomiebaum aufgenommen werden und dieser dann in Zukunft durch die Redakteure erweitert werden kann. Für solche Fälle eignet sich hervorragend das Default Content Modul. Mit diesem ist es möglich, Inhalte, die beim initialen Setup einer Seite erstellt werden sollen, in eigene Module zu exportieren.
Beim Aktivieren dieser Module wird dieser Content dann auf dem System eingefügt. Dies ermöglicht es den Entwicklern, eine Reihe an „Default Contents“ zu erstellen, welche anderen Entwicklern und auch zukünftig den Redakteuren zur Verfügung stehen.

Wenn Sie Fragen zu diesem Blogpost haben, nutzen Sie gerne die Kommentarfunktion. Sie oder Ihr Team benötigen Unterstützung beim Etablieren von Drupal Deploymentstrukturen? Lernen Sie unser Angebot im Bereich Drupal Beratung und Schulungen kennen oder nehmen Sie direkt unverbindlich Kontakt zu uns auf.

Registrieren Sie sich jetzt für unseren kostenlosen Newsletter und bleiben Sie immer auf dem Laufenden

Weitere Blogbeiträge