Composer-basierte Drupal-Projekte können Spaß machen

Als Team, das jahrelang Zeit und Geld in die Entwicklung von Best Practices für das Staging, die Bereitstellung und den Betrieb vieler Drupal-Websites in den Versionen 5 bis 7 investiert hatte, brachte das neue Drupal 8 im Jahr 2015 einige Überraschungen und Herausforderungen mit sich, als die ersten Alpha- und dann Beta-Versionen das Licht der Welt erblickten. Während der gesamte Drupal-Kern bis Drupal 7 im Hauptprojektordner zu finden war, befand sich der gesamte von der Drupal-Gemeinschaft und von Dritten beigesteuerte Code tief unten im Codebaum, wobei der benutzerdefinierte Code für das jeweilige Projekt manchmal schwer von anderen Beiträgen zu trennen war. Konsistenz war nur ein Traum, z.B. mussten die beigetragenen Installationsprofile im gleichen Ordner wie die Installationsprofile des Kerns liegen.

Drupal-Dienstleister haben sich daran gewöhnt. Wir haben sogar das seltsame Szenario hinbekommen, dass jemand ein Zusatzmodul im Unterverzeichnis eines Profils, im Modulverzeichnis des Kerns oder sogar im Modulverzeichnis einer der Websites, die von dieser Drupal-Installation gehostet werden, platziert hat. Und natürlich waren die oben erwähnten Best Practices ausgeklügelt genug, um sich um all diese Drupal-bedingten Merkwürdigkeiten zu kümmern.

Dann kam dieses Symfony-basierte Drupal 8-Biest um die Ecke, und ganz zu schweigen davon, dass sich die Verzeichnis- und Dateistruktur komplett verändert hatte - und zwar zum Besseren, um das gleich vorweg zu nehmen. Hier sind die Highlights:

• Drupal core ist in ein core Unterverzeichnis gewandert und solange man nicht auf Fehlersuche ist oder gar Drupal core pflegt, hat man keinen Grund mehr, jemals wieder in diesen Ordner zu schauen. Das ist core, es ist großartig, es macht seine Arbeit, es ist für Sie da. Und Sie können ihn so belassen, wie er ist. Alle Ihre Entwicklungen, Ergänzungen und was sonst noch so anfällt, gehen an andere Orte. Sie haben nichts mehr mit Drupal Core zu tun. Fantastisch.
• Ein neues Verzeichnis namens vendor mit einer großen Anzahl von Drittanbieter-Paketen oder Bibliotheken aus der PHP-Community, die nicht nur Drupal, sondern auch alle möglichen anderen PHP-basierten Plattformen und Anwendungen bedienen. Auch hier gibt es eine Menge großartigen Code, aber nichts, worüber sich die meisten Drupal-Agenturen Sorgen machen müssten, wenn sie Webanwendungen auf Basis von Drupal erstellen.
• In der Mitte eines Drupal-Projekts gibt es 4 Verzeichnisse, die für uns sind. Hier werden die Zusätze installiert und die Entwicklung findet statt. Direkt in der Wurzel des Webprojekts, nicht tief unten im Baum:
  • /Bibliotheken
  • /Module
  • /Profile
  • /Themen

Bei einem ersten Blick auf die Struktur fand ich das so spannend. Es war so offensichtlich und ich könnte nicht mehr zustimmen: Das war ein großer Schritt in die richtige Richtung. NB: Ja, ich weiß, dass die Umstrukturierung von Drupal 8 viel mehr als das war, und ich bin weit davon entfernt, diese Errungenschaft herunterzuspielen, es ist nur so, dass dieser Blog-Beitrag sich auf die resultierende Struktur konzentriert und was das für unsere Arbeitsabläufe bedeutet.

Aber warte, wie aktualisiere ich dann Drupal Core?

Was am Anfang so toll aussah, bereitete ein paar Wochen später großes Kopfzerbrechen, als das nächste Alpha-Release zur Verfügung gestellt wurde und sich plötzlich herausstellte, dass die bisher erfolgreichen Update- und Deployment-Strategien nicht mehr funktionieren würden. Der Aufruf von drush pm-updatecode funktionierte nicht und warf überall Fehlermeldungen aus. Das Ausführen von Composer war etwas, das ich noch nicht allzu oft gemacht hatte, und ich wusste nicht einmal, wie ich die Datei composer.json aktualisieren sollte, um loszulegen. Zumindest schien dieser Ansatz keinen Sinn zu machen. Die neue Drupal-Core-Tar-Datei herunterladen und diese über den bestehenden Code-Baum kopieren? Irgendwie ein erschreckender Ansatz, bei dem ich mich nie in der Nähe meiner Tastatur und meines Terminals fühlte.

Es war eine Herausforderung, die Community zu diesem Zeitpunkt zu erreichen. Alle waren super beschäftigt. Je tiefer ich in die Materie eindrang, desto offensichtlicher wurde, dass diese Frage noch nicht behandelt worden war: Wie sieht der Lebenszyklus einer Drupal 8-Website aus?

Der beste Rat zu der Zeit war folgender: Laden Sie die neueste Version von Drupal Core herunter, entpacken Sie diese in ein temporäres Verzeichnis. Löschen Sie dann die Verzeichnisse /core und /vendor in Ihrem Web-Root und verschieben Sie diese beiden Verzeichnisse aus dem gerade entpackten Archiv in Ihr Projekt. Danach führen Sie eine Reihe von verschiedenen Befehlen aus und mit ein bisschen Glück sollten Sie mit einem aktualisierten Kern loslegen können. Was?

Richtig, es ist ein bisschen Forschung, Versuch und Irrtum, Diskussionen und einige Projekte mit echter Lebenserfahrung erforderlich, um zu einem völlig neuen Arbeitsablauf für die Wartung von Drupal-Sites aus einer Staging- und Deployment-Perspektive zu gelangen. Und viele Drupal-Spezialisten haben in den letzten 12+ Monaten daran gearbeitet und sind zu dem Schluss gekommen, dass ein auf dem Composer basierender Workflow nicht nur der beste ist, den wir bekommen können, sondern dass er wirklich viel Sinn macht - und es macht großen Spaß!

Composer ist ein großartiges Werkzeug

Zu meiner Überraschung gibt es derzeit eine Menge negativer Geschichten über Composer, vor allem in der Drupal-Community. Das liegt vor allem daran, dass wir als Drupal-Gemeinde derzeit ziemlich viel Neues lernen müssen, und das alles auf einmal. Wir haben alle von der riesigen Anstrengung der Drupal-8-Entwicklung gehört oder waren sogar daran beteiligt, die mehrere Jahre dauerte. Und einige großartige Leute haben die Gemeinschaft sogar verlassen, weil sie mit dem Ansatz nicht einverstanden waren und der Meinung waren, dass die objektorientierte Architektur eine zu große Hürde für die vielen autodidaktischen Modulentwickler darstellen würde.

Aus eigener Erfahrung kann ich nur sagen, das Abenteuer ist großartig. Man muss sich nur darauf einlassen und bereit sein, neue Dinge zu lernen. Wenn man erst einmal drin ist, ist die Entwicklung von Diensten, Plugins und Controllern so einfach und man bekommt großartige Unterstützung von IDEs und anderen Tools.

In diesem Zusammenhang werden wir plötzlich auch vom Composer getroffen. Er braucht unsere Aufmerksamkeit und stählt unsere Produktivität. Ich glaube, das ist der Grund, warum wir derzeit so viel Frustration darüber in unserer Community lesen. Das wird sich zum Besseren wenden. Und zwar schon sehr bald, wie ich finde.

Da ich viel darüber lese, wie andere es machen, bin ich auf ein nettes Projekt auf GitHub gestoßen, das ein Composer-Template für Drupal-Projekte gestartet hat. Es hat auf Anhieb gut funktioniert und was sehr schnell klar wurde, war die Tatsache, dass die Verzeichnisstruktur eines Drupal-Projekts wieder einmal zum Positiven verändert wird.

Nachdem wir diese Vorlage als Blaupause genommen und versucht haben, sie in unseren eigenen Arbeitsablauf einzupassen, der von einigen GitLab- und Ansible-Komponenten beeinflusst ist, haben wir begonnen, sie auf eine Lösung zuzuschneiden, die inzwischen in einem halben Dutzend Projekten in Produktion gegangen ist und hervorragend funktioniert. Sie finden das Projekt unter Drupal 8 Project Template in unserem GitLab-Repository.

So sieht eine solche Struktur aus:

- Projekt Root
  - /config
  - /console
  - /drush
  - /dateien
  - /Einstellungen
  - /Anbieter
  - /web
    - /kern
    - /bibliotheken
    - /Module
      - /contrib
      - /benutzerdefiniert
    - /Profile
      - /contrib
      - /benutzerdefiniert
    - /seiten
    - /themen
      - /beitraege
      - /anpassen
    - index.php
  - .gitignore
  - komponist.json
  - composer.lock

Es gibt nur ein paar Änderungen gegenüber der oben beschriebenen Struktur von Drupal 8:

• Es gibt ein Projektstammverzeichnis, wobei das Drupal-Stammverzeichnis ein Unterverzeichnis davon ist, das /web
• heißt.
• Das Verzeichnis /vendor befindet sich jetzt im Projektstamm und nicht mehr im Drupal-Stammverzeichnis
• Die 3 Verzeichnisse /config, /files und /settings befinden sich ebenfalls auf der Projektebene und sind somit klar getrennt (mehr dazu in einer Minute)
• Die CLI-Tools (Drush und DrupalConsole) haben ebenfalls ihre eigenen Speicherorte

Alle beigesteuerten Module, Themes, Profile und Bibliotheken sind in ihren /contrib Verzeichnissen im Drupal-Root untergebracht und auch unser eigener Code für das Projekt hat dort seine eigenen Unterverzeichnisse.

Was kommt in die Versionskontrolle

Aus der obigen Struktur geht ziemlich klar hervor, was spezifisch für ein Kundenprojekt ist:

• composer.json und composer.lock
• Konfiguration und Einstellungen
• alle custom Verzeichnisse

Alles andere ist reproduzierbar und in keiner Weise einzigartig für ein bestimmtes Kundenprojekt. Aus diesem Grund haben wir beschlossen, nur diese Komponenten in das Repository des Kundenprojekts zu übertragen. Wir wollen aber nicht verschweigen, dass es in der Community Diskussionen zu diesem Thema gibt. Ich erwähne das nur, damit Sie wissen, dass der beschriebene Ansatz der von uns gewählte ist, aber sicher nicht der einzig mögliche.

Nachvollziehbar? Ja, mit nur den 3 oben genannten Komponenten kann die gesamte Drupal-Site eingerichtet werden, entweder für die Produktion oder für einen anderen Entwickler, der dem Team beitritt. Fast. Was im Repository fehlt und immer noch nicht reproduzierbar ist, ist das Dateiverzeichnis. Hier werden Bilder und Dokumente gespeichert, die in unserem Workflow anders verwaltet werden. Da es sich meistens um binäre Daten handelt, und auch um ziemlich große Dateien, gibt es verschiedene Optionen, wie diese Dateien behandelt werden können. Das gehört nicht in den Rahmen dieses Blogbeitrags und wir werden das an anderer Stelle behandeln. Das Gleiche gilt übrigens auch für die Datenbank.

Wie man das alles nutzt: der Arbeitsablauf

Alles, was sich im Repository befindet, ist das, was man braucht, um die Drupal-Site einzurichten. Sehr leicht und einfach zu handhaben. Aber bevor wir beschreiben, wie man die Site auf einem anderen Host einrichtet, schauen wir uns an, wie man loslegt. Es ist nur ein einziger Befehl erforderlich:

composer create-project lakedrops/d8-project [DIRNAME] --stability dev --no-interaction 

Ersetzen Sie [DIRNAME] einfach durch den Zielort, an dem das neue Projekt erstellt werden soll, und ein paar Minuten später haben Sie eine voll funktionsfähige Drupal-Umgebung und können sofort mit der Entwicklung des Kundenprojekts beginnen. Sogar das Git-Repository wurde lokal erstellt und Sie können es in ein beliebiges Remote-Repository Ihrer Wahl pushen. Der Quellcode der Projektvorlagen ist Open Source und Sie können ihn in unserem GitLab Repository finden, klonen oder zu ihm beitragen.

Wenn Sie das Projekt auf einem anderen Rechner einrichten wollen, entweder für einen anderen Entwickler, zum Testen oder sogar für die Produktion, checken Sie das Projekt einfach aus Ihrem Git-Repository aus und rufen Sie folgenden Befehl auf:

# Produktionsumgebung
composer install --no-dev --optimize-autoloader --prefer-dist

# Entwicklungsumgebung
composer install --optimize-autoloader --prefer-dist

Dies installiert alle Komponenten (Drupal-Core, Module, Themes und alle Vendor-Pakete) in einem Durchgang und verwendet genau die gleiche Version für jede dieser Komponenten, die Sie in Ihrer Entwicklungsumgebung festgelegt haben. Dies ist möglich, weil composer alle Details über die installierten Komponenten in seiner composer.lock Datei speichert, so dass die Installation aus diesem Repository genau das gleiche Ergebnis wie beim letzten Mal liefert.

Um bestehende Komponenten zu aktualisieren oder neue hinzuzufügen, editieren wir compose.json in unserer Entwicklungsumgebung und rufen dann Folgendes auf:

composer update 

Damit werden alle Komponenten und ihre Abhängigkeiten automatisch aktualisiert und die Angaben in composer.lock erneut aktualisiert. Ein Commit nach Git und ein erneutes Deployment auf den anderen Hosts wie oben beschrieben ist alles, was Sie tun müssen. OK, um fair zu sein, es gibt zusätzliche Aufgaben wie das Ausführen der Aktualisierungsroutinen von Drupal, das Flushen des Caches und andere Wartungsarbeiten, und wir raten dringend dazu, auch diese Aufgaben zu automatisieren. Aber diese sind in jedem Fall erforderlich, nicht nur in einer Composer-basierten Workflow-Umgebung, und werden daher in diesem Blogbeitrag nicht behandelt.

Das ist so ziemlich alles, was erforderlich ist. Der vollständige Workflow für eine Drupal-Agentur muss auch den Fluss für Einstellungen, Konfigurationen, Dateien, Datenbanken, Stages und andere Bereiche definieren. Auch das sind interessante Themen, aber der Composer-Teil des Workflows basiert auf den oben beschriebenen Bausteinen. Wir finden, das macht Spaß, und wünschen Ihnen viel Spaß dabei.