Environment Context

Worum geht es hierbei?

Was sind environments?

Viele Drupal-Projekte arbeiten mit mehreren Umgebungen (“environments”). Meistens ist das bei uns

• Development für die Entwicklung auf dem lokalen Rechner,
• Staging, das nicht-öffentliche Testsystem zum Ausprobieren neuer Entwicklungen und Updates. Hier arbeiten erdfische und Kund:innen zusammen an Verbesserungen des Systems.
• und Production – das Livesystem, meist öffentlich.

Was wollen wir erreichen?

Die Herausforderung: Manchmal möchte man Features, Einstellungen oder Funktionen entwickeln, die sich je aktuellem environment unterscheiden. Zudem kann es vorkommen, dass die Information, welche environments insgesamt für das Projekt existieren, für eine technische Funktion benötigt wird. Der Beispielfall entstammt einer Fragestellung innerhalb unserer Sites Multisite-Lösung.

Genau dafür haben wir environment_context entwickelt: ein flexibles Modul, das Entwickler:innen erlaubt, die aktuelle Umgebung aus einer zentralen Informationsquelle eindeutig zu identifizieren und für den aktuellen Kontext ein spezifisches Feature zu entwickeln.

Warum war das nötig?

„Es gab keine zentrale Lösung in Drupal. Existierende Module mit einem Bezug zu unterschiedlichen Umgebungen haben für gewöhnlich immer selbst einen neuen Ansatz implementiert und jeweils nur eine bestimmte umgebungsspezifische Einstellung verändert. Wir wollten etwas, das die Information zentralisiert, auf jeden Anwendungsfall skalierbar ist und Aufwände spart.“
– Pascal Crott

Die Notwendigkeit entstand aus der Entwicklung unserer Multi-Site Lösung “Sites”. In komplexen Multisite-Systemen gibt es oft mehrere völlig unterschiedliche Funktionen, die auf die Information der existierenden environments zugreifen und diese nutzen müssen. Wir wollten diese Information an nur einer Stelle zentral pflegen, aber das gab es bis jetzt nicht. Jedes Modul hat die Fragen “Was ist eigentlich das aktive environment?” und “Was für environments gibt es eigentlich, für die wir eigene settings im UI ermöglichen wollen?” für sich selbst beantwortet und brauchte eine eigene Konfiguration.

Also haben wir eine eigene Lösung gebaut: modular, generisch, und offen für verschiedene Ansätze zur Environment-Erkennung. Wer mag, kann eigene Logiken integrieren oder bestehende nutzen.

Was sind die Vorteile?

• Verlässlichkeit: Das aktuelle environment ist jederzeit programmatisch verfügbar; ebenso die Information, welche environments existieren.
• Nahtlose Integration in Drupal-Subsysteme: environment_context dockt direkt an bestehende Drupal-Mechanismen an und gibt deren Lösungsansätze weiter oder erweitert sie.
  • Auch andere Module profitieren: Die Conditions API kann ebenfalls genutzt werden! Im Idealfall verknüpft man also Environment Context mit unserem Modul Conditions und kann nun ganz einfach im UI Bedingungen auf Basis der aktuellen Umgebung erstellen.
• Völlige Flexibilität: Der Mechanismus ist erweiterbar. Mit environment_context können existierende Techniken anderer Modulen mitbenutzt werden oder es kann ein ganz eigener “Point of Truth” für die vorhandenen environments definiert werden. Es besteht keine Abhängigkeit auf bestimmte andere Module, aber Kompatibilität mit allen.
• Sparsamkeit: Bisherige Insellösungen werden zentralisiert und die Mehrfachpflege entfällt
• Multisite-kompatibel: In Multisite-Lösungen wie unserer Sites Suite arbeitet das Modul auch: Domains können für Live-Multisites, aber auch für Umgebungen eingetragen werden. Environment Context berücksichtigt das und weiß, welche Domain zu welchem Environment gehört.

Beispiele für die Anwendung

Umgebungsspezifische Inhalte pflegen: Stage-Domains in Sites

Ein Multidomain-System mit verschiedenen Webseiten liegt vor, das über ein zentrales Drupal verwaltet wird. Dafür wurde unser Sites-System eingesetzt. Nun soll an einer Site die Domain definierbar sein, unter der sie zu erreichen ist, beispielsweise www.IhreSite.com.
Aber auf der Testumgebung soll an dieser Stelle die Stage-Domain stehen, beispielsweise stage.IhreSite.com.
So können Anpassungen am Multisite-Projekt nahtlos auf der Stage getestet werden.

Das Besondere: Die Domain wird hier als Content gepflegt, nicht als Konfiguration. Damit scheidet ein rein konfigurationsbasierter Ansatz wie config_split aus. Genau hier greift environment_context: Das Modul stellt die Information bereit, auf welcher Umgebung wir uns befinden, und macht sie dort verfügbar, wo sie gebraucht wird, auch auf Content-Ebene. So kann das System automatisch die passende Domain je Umgebung auflösen, ohne dass dafür eine separate Lösung gebaut werden muss.

Weitere Anwendungen im selben Setup

Neben der Domain-Pflege profitieren auch andere Funktionen von der zentralen Umgebungsinformation. Das Modul environment_indicator etwa zeigt durch eine Färbung der Admin-Toolbar visuell an, auf welcher Umgebung man sich befindet, und schützt so vor versehentlichen Änderungen im Livesystem. Auch config_split, das umgebungsspezifische Konfigurationsunterschiede verwaltet, arbeitet mit einer eigenen Environment-Erkennung.

Normalerweise implementiert jedes dieser Module eine eigene Logik dafür – diese können oft in ihrer technischen Ausprägung stark voneinander abweichen und uneinheitlich aussehen. In einem komplexen Multisite-System kommen schnell weitere hinzu. environment_context wird zur Brücke: Alle Module greifen auf dieselbe, zentral gepflegte Information zu. Die Mehrfachpflege entfällt, und neue umgebungsabhängige Funktionen lassen sich ohne zusätzlichen Konfigurationsaufwand anbinden.

Ein grafisches Beispiel

environment_context ist an sich ein “unsichtbares” Modul. Die Konfiguration findet normalerweise auf Code-Ebene statt. Mit dem folgenden Screenshot können wir jedoch ein mögliches Beispiel visualisieren:

Wir sehen hier die Konfiguration eines Content-Blocks. Für diesen Block kann in den “Visibility Settings” (also Sichtbarkeitseinstellungen) definiert werden, auf welchen Umgebungen er erscheinen oder nicht erscheinen soll. Für eine einheitliche Pflege wird hier unser Conditions Modul genutzt. Es wird auf die nun allgemein zugängliche, zentral gepflegte Information zurückgegriffen, welche environments existieren. Diese werden als Liste von Checkboxen angezeigt und sind einzeln aktivierbar. Wie zuvor erwähnt, kann die Liste sich aus einer beliebigen anderen Quelle wie z.B. config_split speisen. environment_context sorgt dafür, dass sie auch hier verfügbar ist.

Fazit

environment_context ermöglicht zentralisierten Zugriff auf die Information der aktuellen Website-Umgebung, beispielsweise Local / Stage / Production, um damit alles zu steuern, was je Umgebung unterschiedlich sein soll. Ebenso sind sehr individuelle Umgebungskonstrukte möglich, beispielsweise für hochverfügbare Systeme, die jeweils mehrere Prod- und Testumgebungen betreiben, um nahtlose Wechsel zu ermöglichen.

Es ist eine wirkungsvolle Brücke, um verschiedene Rädchen im großen Drupal-Getriebe komplexer Websysteme zu verbinden. Je umfangreicher Ihre Weblandschaft wird, desto mehr freut erdfisch sich darauf, starke Lösungen zu entwickeln.