Wer eine Website über längere Zeit betreibt, muss an dieser Website oft Änderungen und Erweiterungen vornehmen. Das gilt insbesondere für Content Management Systeme wie WordPress, Drupal und Joomla.
Die Zielgruppen dieser Systeme sind durchaus unterschiedlich. Einerseits werden sie gern von Anwendern genutzt, die die individuelle Konfiguration der Website über die Benutzeroberfläche im Browser vornehmen und nur im Notfall selbst programmieren wollen.
Andererseits werden diese Systeme auch von Web-Agenturen als Basis für Kunden-Projekte genutzt. In diesem Fall werden, neben den Konfigurationsänderungen, oft individuell programmierte Features für die Kunden der Agentur erstellt die nach dem Launch der Website supported werden müssen.
In den meisten Fällen einigt man sich zwischen Agentur und Kunde auf eine Umgebung mit einer produktiven Live-Site und mindestens einer oder auch mehreren Test-, Staging- und Entwicklungs-Websites. Auch für die kleinste Website bietet es Vorteile wenn nicht „live“ konfiguriert wird. Die Änderungen können „in Ruhe“ in einer Test-Umgebung gemacht werden und bei Gefallen in die Live-Site übertragen werden. Die „Übertragung“ ist allerdings gar nicht so einfach zu realisieren, weil die Änderungen oft viele „Kleinigkeiten“ umfassen und im schlimmsten Fall auf der Live-Site manuell nachvollzogen werden müssen. Je mehr Personen an der Entwicklung der Website arbeiten, umso wichtiger sind klare Vereinbarungen, wer an welcher Stelle und zu welcher Zeit etwas ändern darf.
Programmcode für zusätzliche Plugins, Erweiterungen, Module, Themes und Templates lässt sich gut in Versionskontrollsystemen wie Git verwalten, wie aber geht man mit Konfigurationseinstellungen um? Ich denke da an die Positionierung von Blöcken, Menüpunkte, Einstellungen in Themes, der Name der Website, die Datumsformate und vieles andere mehr.
Konfigurationen werden in LAMP-basierten Systemen gern in der Datenbank verwaltet und sind daher nicht mit gängigen Mitteln wie Git versionierbar.
In diesem Blog-Post zeige ich den Ansatz, den Drupal bei der Verwaltung von Konfigurationen verfolgt.
Drupal Konfigurationen
Das Drupal CMS war anfangs eine Platform für Site-Builder. Wie in einem Lego-Baukasten liessen sich bereits vor mehr als 15 Jahren Inhaltstypen, Felder, Vokabulare, Tags, Benutzerprofile, Rollen und Berechtigungen über eine Browser-Oberfläche „zusammenklicken“. Drupal war eine „No-Code Plattform“ (und ist es auch heute noch). Ein grosses Problem war, dass die Sites oft „live“ konfiguriert wurden und ab einer gewissen Komplexität oder bei einem Personalwechsel der Aufbau der Site für Dritte nicht mehr nachvollziehbar war. Ein geordneter Entwicklungs-Workflow war schwierig einzuhalten. Wer jemals in WordPress über längere Zeit mit mehreren Personen mit dem Divi-Theme gearbeitet hat, kann vermutlich nachvollziehen, was ich meine. Solange man so ein System versteht und verantwortlich anwendet, ist alles gut. Wenn Hektik und Bastelei ins Spiel kommen, wird es schwierig.
In Drupal war oft die Folge, dass sich aus der „blanken Not“ viele Site-Builder zu Developern weiterentwickelten und auf die eine oder andere Weise versuchten Konfigurationen in Code zu „verwandeln“. Mit der Einführung von Drupal 8 im Jahr 2015 wurde das bis heute verwendete Konfigurations-Management eingeführt.
Jede Konfiguration in Drupal kann in Code (YAML Dateien) oder über die Benutzeroberfläche erstellt und verändert werden! Jede Konfiguration erhält einen eindeutigen Universally Unique Identifier (UUID) und kann importiert und exportiert werden. Du kannst entweder die gesamte Konfiguration als Dateipaket (Vollständiges Archiv) exportieren oder nur ein einzelnes Element.
Durch diese Vorgehensweise lassen sich die Konfigurationen mehrerer Drupal-Sites vollständig synchronisieren. Die Synchronisierung ist sehr hilfreich wenn im laufenden Betrieb Konfigurationen verändert werden oder neu hinzukommen.
Wie geht das genau?
Bei der Installation einer Drupal-Site wird vom Installer automatisch ein Synchronisiations-Verzeichnis angelegt und in die settings.php Datei eingetragen. Der Name des Verzeichnisses ist lang und schwierig zu erraten. Solange es nicht zur Synchronisierung benutzt wird, ist dieses Verzeichnis leer.
$settings['config_sync_directory'] = 'sites/default/files/config_--dEvmNjwZs-N4C2ffdZTbsgFsjfjjHzuwjkKKHgFFDdCyjHzExsPacYEm2D-buEqQ/sync';
Hinweis: Das Verzeichnis kann aus Sicherheitsgründen auch ausserhalb des Webverzeichnisses angelegt werden.
Wird nun eine Kopie der Site erstellt und zur Test-Site bestimmt, so verfügen alle Konfigurationen der Live- und der Test-Site über identische UUIDs.
Wird innerhalb der Test-Site eine neue Konfiguration hinzugefügt, entsteht eine neue UUID, die auf der Live-Site noch nicht vergeben ist.
Wird eine bestehende Konfiguration mit bereits existierender UUID verändert, so kann der neue Code dieser Konfiguration mit dem alten Code verglichen werden.
Beispiel: Veränderter Seitenname
Ich habe eine Test-Site erstellt (Kopie der Live-Site) und die Konfiguration der Live-Site dort importiert. Dann habe ich den Seitennamen auf der Test-Site verändert, damit man sieht, dass man sich auf der Test-Site befindet. Im Synchronisierungsbereich (/admin/config/development/configuration) der Test-Site wird mir ein Hinweis angezeigt, dass die aktuelle Konfiguration verändert wurde.
Es besteht die Möglichkeit sich die Unterschiede innerhalb der Konfigurationen anzeigen zu lassen. Wenn ich die Konfiguration der Live-Site (Im Screenshot Bereitgestellt – rechte Seite) wieder importieren würde, so würde meine aktive Konfiguration (Im Screenshot Aktiv – linke Seite) überschrieben werden.
Der Im- und Export funktioniert zuverlässig und problemlos. Nach ein paar Übungen kann man sehr gezielt einzelne Views, Felder und andere Entitäten von einer auf die andere Website übertragen. Übertragen wird entweder ein einzelnes Element oder die komplette Site-Konfiguration.
Workflow-Varianten
Im letzten Beispiel hatte jede Drupal-Site ihr eigenes Sync-Verzeichnis. Die Konfiguration der Live-Site musste exportiert und in das Verzeichnis der Test-Site geladen werden. Dann konnte man die Konfiguration sehen und in die Test-Site importieren. Ausser dieser Vorgehensweise gibt es zahlreiche Varianten, wie man den Workflow gestalten kann.
Ein gemeinsames Verzeichnis
Die naheliegendste Idee ist vermutlich ein gemeinsames Sync-Verzeichnis zu nutzen. Wenn beide Sites auf dieses Verzeichnis zugreifen, so können Änderungen an der Test-Site einfach in die Live-Site übernommen werden. Das Modul Config Direct Save erspart den Export und Import der gesamte Konfiguration. Es schreibt die aktuelle Konfiguration der gewünschten Site in das gemeinsame Verzeichnis. Dieses Szenario ist perfekt für eine 100% synchrone Test- und Live-Site. Es ist auch hilfreich, wenn man die Test-Site „kaputt-konfiguriert“ hat und wider den exakt gleichen Konfigurationsstand wie die Live-Site haben will. Wenn allen Mitarbeitern klar wird, dass sie an der Test-Site nichts kaputt machen können, entstehen oft interessante Konfigurationslösungen.
Mehrere gemeinsame Verzeichnisse
Der Vorteil eines gemeinsamen Verzeichnisses ist auch gleichzeitig der Nachteil. Wenn ich beispielsweise den Namen der Test-Site verändere, sind Test- und Live-Site nicht mehr synchron. Oft will man das auch gar nicht, denn meistens sind auf Test-Sites ein paar Konfigurationseinstellungen anders als auf der Live-Site. Bei Drupal wird beispielsweise gern das Devel-Modul (Hilfsmittel für Entwickler und Site-Builder) bei der Entwicklung genutzt, das man auf produktiven Seiten aber nicht installieren sollte.
Es wäre daher sinnvoll, die Konfiguration auf mehrere Verzeichnisse aufzuteilen, die man bei Bedarf synchronisieren kann. Genau das macht das Configuration Split Modul. Der Vorteil ist, dass man die relevante Konfiguration für die Live-Site in einem Vorgang importieren kann.
Mehrere gemeinsame Verzeichnisse unter Versionsverwaltung
Als nächsten Schritt können die relevanten Sync Verzeichnisse unter Versionsverwaltung gestellt und in regelmässigen Abständen auf die Live-Site deployed werden. Mit dieser Variante werden dann wirklich alle Anforderungen abgedeckt. Web-Agenturen haben einen lückenlosen Nachweis wer, was, an welcher Stelle verändert hat und auch ambitionierte Kunden können in dieses System eigene Konfigurationsänderungen über die Benutzeroberfläche integrieren.
Fazit
Das Interessante an der Art und Weise wie Drupal mit Konfigurationen umgeht ist die eindeutige Identifizierung aller Elemente mittels UUID und der Umwandlung der Konfigurationen in Code. Dadurch ist es auf vielfältige Weise möglich, Drupal Websites zu synchronisieren und Entwicklungs-Workflows je nach Bedarf festzulegen. Diese Grundvoraussetzungen sind bereits im Drupal Core Paket enthalten und können ohne weitere zusätzliche Module genutzt werden.
Links
https://www.drupal.org/docs/configuration-management
tl;dr: Konfigurationsmanagement mit Drupal ist einfach und skalierbar
Schreibe einen Kommentar