Upgrade von Drupal 8 auf Drupal 9

By Oliver Davies

Der Support für Drupal 8 wird zu November 2021 eingestellt. Daher ist jetzt genau der richtige Zeitpunkt, die Sicherheit Ihrer Website zu gewährleisten und von allen Funktionen zu profitieren, die in Drupal 8 entwickelt wurden – aber auf einer „Codebasis, die schlanker und sauberer ist“. Nachdem ich die Inviqa-Websites vor zwei Jahren auf Drupal 8 entwickelt hatte, lag es mir sehr am Herzen, das Upgrade von inviqa.com und inviqa.de auf Drupal 9 so früh wie möglich durchzuführen und meine Erkenntnisse weiterzugeben.

Wir freuen uns, sagen zu können, dass das jüngste Upgrade deutlich einfacher und schneller war als unser Upgrade von Drupal 7 auf Drupal 8 im Oktober 2019. Das war damals ein gewaltiges Projekt: Ausgangspunkt war ein neues und leeres Code Repository; die Architektur der Inhalte der Website musste neu gestaltet werden und es mussten neue benutzerdefinierte Module und Themes geschrieben werden – im Prinzip fingen wir damals wieder bei null an.

Mit der Umstellung auf primär objektorientierten PHP-Code, der Ergänzung einer Reihe von Symfony-Komponenten und anderen Abhängigkeiten von Dritten, einer neuen Template-Engine (Twig) und einem neuen Abhängigkeitsmanagement-Tool (Composer) hat sich bei der Weiterentwicklung von Drupal 7 zu Drupal 8 hinter den Kulissen sehr viel getan.

Angesichts dieser Veränderungen mussten wir damals die benötigten Daten migrieren und versuchen, anwendbaren Code zu aktualisieren und weiterzuverwenden – damit war der Wechsel von Drupal 7 auf Drupal 8 eher ein Neuanfang als ein einfaches Upgrade von einer Version zur nächsten, wie es bei diesem Projekt der Fall war.

Kein großer Umbau

Drupal 9 wurde in Drupal 8 entwickelt und es wurde nur eine minimale Anzahl an grundlegenden Änderungen vorgenommen. Module und Themes, die ursprünglich für Drupal 8 geschrieben wurden, können daher auch gleichzeitig in Drupal 9 laufen. Das bedeutet, dass eine 8.x-1.0-Version eines Moduls auch Drupal 9 unterstützen kann (und erklärt, warum Contrib auf semantische Versionierung umgestiegen ist, um das klarer zu machen).

8.x Veröffentlichung eines Contrib-Moduls mit Drupal 9-Kompatibilität
8.x Veröffentlichung eines Contrib-Moduls mit Drupal 9-Kompatibilität
Veröffentlichung des Contrib-Moduls mit semantischer Versionskontrolle, kompatibel mit Drupal 8 und 9
Veröffentlichung des Contrib-Moduls mit semantischer Versionskontrolle, kompatibel mit Drupal 8 und 9

Daher konnten wir einen Großteil des Upgrades innerhalb der Drupal-8-Versionen der Websites vornehmen. Die meisten der von uns verwendeten Module haben Versionen, die mit Drupal 8 und Drupal 9 kompatibel sind, sodass wir diese upgraden konnten, bevor wir das Update von Drupal selbst durchgeführt haben.

Was unseren benutzerdefinierten Code betrifft, konnten wir Verwendungen von veraltetem Code (Code, der zum Löschen in Drupal 9 markiert war) während des Drupal-8-Lebenszyklus entfernen. Für unser Theme und den Großteil unserer Module mussten also nur ihre .info.yml-Dateien aktualisiert werden, um darzustellen, dass sie D9-kompatibel sind.

Das ist eine einfache, einzeilige Änderung:

- core: 8.x

+ core_version_requirement: ^8.8 || ^9

Der alte Core Key hat nur einen einzigen Wert für die Drupal-Version akzeptiert, für die ein Projekt gedacht war, aber das in Drupal 8.8 hinzugefügte core_version_requirement ermöglicht es, mehrere Versionen hinzuzufügen – zum Beispiel 8 und 9 gleichzeitig.

Wir haben Tools wie das Upgrade-Status-Modul und das Drupal-Check-Tool verwendet, um unsere Fortschritte zu sehen und nach veraltetem Code zu suchen, der upgegradet werden müsste. Außerdem haben wir auf unsere bestehenden automatisierten Tests und Qualitätsprüfungen gesetzt, um sicherzustellen, dass alles weiter so funktioniert wie erwartet.

Inkrementelle Upgrades

Alle bisherigen Änderungen waren rückwärtskompatibel, funktionierten also sowohl mit Drupal 8 als auch mit Drupal 9. Wir konnten sie daher auf verschiedene Pull-Anforderungen (was die Überprüfung erleichterte) und mehrere Releases und Deployments aufteilen, sodass sie getrennt voneinander getestet werden konnten. Das bedeutete ein geringeres Risiko, als wenn wir ein großes Release für alles hätten machen müssen.

Wenn wir infolge von Änderungen auf ein Problem gestoßen sind, konnten wir diese konkrete Änderung rückgängig machen, anstatt mit den vollständigen Websites zu Drupal 8 zurückkehren zu müssen.

Verschiedene Pull-Anfragen
Verschiedene Pull-Anfragen

Updaten von Drupal mit Composer

Nach all den anderen Updates konnten wir Drupal mithilfe von Composer updaten. Wir haben das drupal/core-recommended-Projekt sowie drupal/core-composer-scaffold und drupal/core-dev verwendet. Für jedes davon haben wir die Versionen von ^8.9 (alles größer oder gleich 8.0.0, aber nicht 9.0) bis ^9.0.0 (alles größer als 9.0.0, aber nicht 10) aktualisiert und sind dabei den Composer-Empfehlungen auf Drupal.org gefolgt.

Mit der aktualisierten composer.json-Datei und wegen der zusätzlichen Abhängigkeiten der Website haben wir diesen Befehl ausgeführt, um das Update von Drupal durchzuführen:

composer up drupal/core-* --with-all-dependencies composer/installers symfony/* consolidation/* tightenco/collect

Damit wurden die Drupal-Core-Pakete von 8.9.14 auf 9.1.8 upgegradet und gleichzeitig die Abhängigkeiten dieser Pakete upgedatet.

Grundlegende Änderungen

Nachdem wir alle rückwärtskompatiblen Änderungen angewandt hatten, gab es auch einige grundlegende Änderungen, die für Drupal 9 gelten. Dank des inkrementellen Release-Ansatzes konnten wir diese jedoch in einem einzigen Deployment zusammen¬fassen.

Einige Module hatten verschiedene Versionen für Drupal 8 und 9, aber nicht eine für beide. In diesem Fall musste das betreffende Modul entfernt und die neue Version nach dem Update von Drupal hinzugefügt werden.

Getrennte Releases für ein Contrib-Modul, eines mit Drupal 8-Kompatibilität, eines mit Drupal 9-Kompatibilität
Getrennte Releases für ein Contrib-Modul, eines mit Drupal 8-Kompatibilität, eines mit Drupal 9-Kompatibilität

Einige Module hatten keine Drupal-9-Versionen, sodass wir Patches aus ihren Issue-Queues anwenden mussten, um sie kompatibel zu machen. Das ging ganz einfach mithilfe eines Composer-Plug-ins – Composer Patches –, das dafür gesorgt hat, dass die Patches automatisch angewandt und nach dem Update dieser Module wieder angewandt wurden.

Wir hatten ein Problem mit einer Drupal-9-Version eines Moduls, aber konnten das Problem mit Unterstützung der Änderungssätze von Drupal lösen und ein Patch für das Modul einreichen, mit dem das Problem beseitigt wird.

Fazit

Wir haben die Websites inviqa.com und inviqa.de ohne große Umbauaktivitäten von Drupal 8 auf Drupal 9 upgegradet – unter Beibehaltung all unserer benutzerdefinierten Module und Themes (mit einigen sehr kleinen Modifikationen), ohne Ausfallzeiten und verteilt auf mehrere Releases, um Überprüfungen zu vereinfachen und das Risiko zwischen Deployments zu minimieren.

Wir haben vier interne Pull-Anforderungen erstellt, überprüft und zusammengeführt, 15 Drupal-Module auf ihre Drupal-9-kompatiblen Versionen aktualisiert, Patches auf vier Module (davon ein Modul, das wir geschrieben und bereitgestellt haben) angewandt und insgesamt 59 Dateien aktualisiert, um dieses Upgrade abzuschließen.

Mit dem vorherigen Upgrade von Drupal 7 auf 8 war ein Team aus Technikern, Designern, UXlern und Projektmanagern mehrere Monate beschäftigt, während dieses Drupal-9-Upgrade von nur einem Techniker innerhalb weniger Tage (gemessen an der tatsächlich aufgewandten Zeit) durchgeführt wurde, und ich habe von anderen Seiten Ähnliches gehört.

Dries Buytaert hat das in seinem Blogpost über Drupal 9 auf den Punkt gebracht:

Die große Sache mit Drupal 9 ist, dass es keine große Sache sein sollte.