Änderungen von Abhängigkeiten erkennen: wöchentliche Modultests mit GitLab CI

Nutzung von GitLab-Vorlagen für proaktive Modultests

Die Anpassung deiner Drupal-Module an das sich ständig weiterentwickelnde Drupal-Ökosystem ist entscheidend für Stabilität und Wartbarkeit. Die Kompatibilität von Modulen mit verschiedenen Versionen des Drupal-Kerns und anderen Abhängigkeiten manuell zu testen, kann jedoch ein zeitaufwändiger und fehleranfälliger Prozess sein. Zum Glück bietet Drupal eine leistungsstarke Lösung: die GitLab CI Templates. Diese Vorlagen bieten eine vorkonfigurierte Umgebung für die Durchführung automatisierter Tests und stellen sicher, dass deine Module für jedes Upgrade oder jede Änderung bereit sind.

Die GitLab CI Templates - deine Grundlage für automatisierte Tests

Die GitLab CI Templates sind eine Sammlung von vorgefertigten Konfigurationsdateien, die den Testprozess für Drupal-Module vereinfachen sollen. Sie bieten einen robusten Rahmen für die Durchführung verschiedener Tests in einer einheitlichen und zuverlässigen Umgebung.

Was können die Templates leisten?

Diese Vorlagen sind so konzipiert, dass sie eine Vielzahl von Testszenarien abdecken, z. B:

• Testen gegen mehrere Drupal-Versionen: Das ist der Hauptvorteil. Die Vorlagen sind so konfiguriert, dass sie Tests für die aktuelle Version von Drupal Core sowie für frühere und zukünftige Haupt- und Nebenversionen von Drupal Core durchführen. So kannst du Kompatibilitätsprobleme proaktiv erkennen, bevor sie sich auf dein Projekt auswirken.
  • Testen gegen zukünftige Versionen: So stellst du sicher, dass dein Code mit den kommenden Funktionen funktioniert und auf Abkündigungen vorbereitet ist.
  • Testen gegen frühere Versionen: Hilft bei der Abwärtskompatibilität, wenn du ältere Drupal-Versionen unterstützen musst.
• Umfassende Testtypen: Die Vorlagen bieten Unterstützung für:
  • Linting: Statische Analyse, um Verstöße gegen den Code-Stil zu erkennen.
  • Statische Code-Analyse: Eingehendere Analyse auf potenzielle Fehler und Schwachstellen.
  • Unit Tests: Stelle sicher, dass die einzelnen Komponenten deines Moduls korrekt funktionieren.
  • Und mehr: Du kannst die Testsuite nach Bedarf um Integrationstests, Funktionstests und andere Tests erweitern.

Einfache Einrichtung - bereit für MRs, Commits und Releases

Und das Beste daran? Diese Vorlagen sind unglaublich einfach einzurichten. Sie sind so konfiguriert, dass sie automatisch ausgeführt werden, wenn:

• Merge Requests erstellt oder aktualisiert werden: Fange mögliche Probleme ab, bevor du den Code zusammenführst.
• Commits in deinen Entwicklungszweigen gemacht werden: So stellst du sicher, dass deine Änderungen keine bestehenden Funktionen zerstören.
• Neue Versionen deines Moduls veröffentlicht werden: Überprüfe, ob sich die neue Version nahtlos in den Drupal-Kern und andere Module integrieren lässt.

Damit dies für dein Modul funktioniert, musst du nur eine Datei namens .gitlab-ci.yml im Stammverzeichnis des Modulcodes erstellen. Sie sollte diese Zeilen enthalten:

include:
  - project: $_GITLAB_TEMPLATES_REPO
    ref: $_GITLAB_TEMPLATES_REF
    file:
      - '/includes/include.drupalci.main.yml'
      - '/includes/include.drupalci.variables.yml'
      - '/includes/include.drupalci.workflows.yml'

Das ist alles, was du brauchst, um alle Voreinstellungen aus den Vorlagen zu übernehmen, die von der Community gepflegt werden. In manchen Fällen musst du die Einstellungen an deine eigenen Bedürfnisse anpassen. Alle verfügbaren Optionen findest du in der Dokumentation zu den GitLab CI-Vorlagen.

Empfohlene Konfigurationsänderungen

Im Laufe der Jahre haben wir gelernt, dass automatisierte Tests nur mit den folgenden Anpassungen wirklich wertvoll sind:

• Keine Fehler für PHPStan, PHPCS, CSpell zulassen
• Erhöhe den PHPStan-Level auf 6

Das Verhindern von Testfehlern, d.h. dass du eine Warnung erhältst, wenn etwas fehlschlägt, kannst du erreichen, indem du die entsprechenden Aufgaben in deiner .gitlab-ci.yml Datei änderst:

cspell:
  allow_failure: false
phpcs:
  allow_failure: false
phpstan:
  allow_failure: false
phpstan (next minor):
  allow_failure: false
phpstan (next major):
  allow_failure: false

Um den Level für PHPStan zu erhöhen, brauchst du eine Datei namens phpstan.neon im Stammverzeichnis deines Moduls mit den folgenden Anweisungen:

parameters:
  level: 6

Je nach Art deines Moduls und je nachdem, welche Arten von Warnungen auftauchen, die du wahrscheinlich ignorieren willst, können weitere Anweisungen in dieser Datei folgen.

Stabile Module und unbemerkte Komponenten-Updates

Die Kompatibilität deiner Drupal-Module aufrechtzuerhalten, ist eine ständige Aufgabe. Module, die über einen längeren Zeitraum nicht aktualisiert wurden - wir bezeichnen sie als stabil oder ausgereift - können schnell hinter das aktuelle Drupal-Ökosystem zurückfallen. Ohne regelmäßige Tests können subtile Änderungen im Drupal-Kern oder in anderen Modulen zu unbemerkten Komponentenaktualisierungen führen - Probleme, die nicht sofort auffallen, aber später Probleme verursachen können. In diesem Kapitel erfährst du, warum diese Module besondere Aufmerksamkeit brauchen und wie du diese potenziellen Probleme proaktiv erkennen und angehen kannst.

Warum stabile Module besondere Aufmerksamkeit brauchen

Module, die keine aktuellen Updates erhalten haben, sind oft auf ältere Versionen von Drupal Core oder anderen Modulen angewiesen. Dadurch entsteht eine Abhängigkeitskette, und selbst kleine Änderungen an einem Teil dieser Kette können zu Kompatibilitätsproblemen führen. Je länger ein Modul unangetastet bleibt, desto wahrscheinlicher ist es, dass sich seine Abhängigkeiten weiterentwickelt haben und desto größer ist das Risiko, dass Komponenten unbemerkt aktualisiert werden.

Unbemerkte Komponentenaktualisierungen - Die Risiken

Ohne regelmäßige Tests können sich diese Aktualisierungen wie folgt äußern:

• Änderungen im Verhalten: Die Funktionalität eines Moduls kann sich aufgrund einer neueren Version des Drupal-Kerns geringfügig ändern.
• Veraltete Funktionalitäten: Funktionsaufrufe oder APIs, die früher unterstützt wurden, können in neueren Versionen entfernt werden.
• Sicherheitsschwachstellen: Ältere Module sind möglicherweise nicht gegen neu entdeckte Sicherheitslücken gepatcht.

Proaktives Testen ist der Schlüssel

Um diese Risiken zu minimieren, ist es wichtig, stabile Modulversionen regelmäßig mit den aktuellen und zukünftigen Versionen von Drupal Core zu testen. Hier kommen wieder die GitLab CI Templates ins Spiel.

Ein zusätzlicher Vorteil dieses Ansatzes ergibt sich, wenn ein neuer Merge in der Warteschlange auftaucht, der ein Problem in deinem Modul behebt, und die Pipelines plötzlich Fehler anzeigen, die nichts mit dieser Korrektur zu tun haben. Wäre das Modul getestet und der neue Fehler proaktiv behoben worden, wäre das nicht passiert.

Wöchentlich geplante Tests

Das Testen deiner Drupal-Module sollte kein einmaliges Ereignis sein, das durch einen neuen Commit ausgelöst wird. Um wirklich langfristige Stabilität zu gewährleisten und unbemerkte Updates von Komponenten zu verhindern, brauchst du einen konsistenten, automatisierten Testprozess. In diesem Kapitel erfährst du, wie du wöchentlich geplante Tests mit den GitLab CI-Vorlagen einrichtest.

Einrichten von wöchentlich geplanten Tests über die GitLab-Benutzeroberfläche

Die gute Nachricht ist, dass es unglaublich einfach ist, diese wöchentlichen Tests einzurichten. So geht's:

1. Rufe die GitLab-Seite deines Moduls auf, z. B. https://git.drupalcode.org/project/eca (ersetze eca durch den Kurznamen deines Moduls)
2. Suche in der linken Symbolleiste im Bereich "Build" nach Pipeline Schedules
3. Konfiguriere den Zeitplan: Klicke auf die Schaltfläche "Neuer Zeitplan", um eine neue geplante Pipeline zu erstellen. Hier kannst du die Häufigkeit, die Tageszeit und den Zweig festlegen, der getestet werden soll.

GitLab führt die gleichen Tests wie oben beschrieben durch, indem es die bereits vorhandene Konfiguration in der .gitlab-ci.yml Datei des konfigurierten Zweigs verwendet.

Anwendung des Ansatzes auf private benutzerdefinierte Module

Der automatisierte Testprozess, den wir bisher beschrieben haben, ist in erster Linie für Module gedacht, die für Drupal freigegeben wurden. Die gleichen Prinzipien - konsequentes Testen und proaktives Erkennen von Kompatibilitätsproblemen - gelten jedoch auch für private benutzerdefinierte Module. In diesem Kapitel wird gezeigt, wie du diesen Ansatz auf deine eigene private Modulentwicklung ausweiten kannst. Dazu brauchst du nur eine eigene Instanz von GitLab, in der du benutzerdefinierte Module privat halten kannst, während du dieselben Infrastrukturkomponenten für Pipelines nutzt.

Damit das funktioniert, fügst du deinem benutzerdefinierten Modul auf deiner eigenen GitLab-Instanz eine .gitlab-ci.yml Datei hinzu und kopierst den folgenden Inhalt hinein:

include:
  - remote: 'https://gitlab.lakedrops.com/gitlab-ci-cd/drupal/-/raw/main/private-modules.yml?ref_type=heads'

Hier wird die Vorlage aus unserem Drupal CI-Projekt verwendet. Du kannst es entweder direkt verwenden oder das Projekt in deine eigene GitLab-Instanz klonen und es dort selbst pflegen.

Zusätzlich zur CI-Konfiguration musst du auch deine eigenen GitLab-Runner bereitstellen, da wir die Infrastruktur der Drupal Association nicht nutzen können, um unsere privaten Tests durchzuführen. Um einen Runner für dein Projekt einzurichten, gehst du zu den CI/CD-Einstellungen des Projekts auf deiner GitLab-Instanz und folgst den Anweisungen im Abschnitt "Runner". Verwende einfach Docker als Ausführungsprogramm für den Runner und ein beliebiges PHP-Image als Startpunkt. Die CI-Vorlagen bringen ihre eigenen Docker-Images mit, die zum Ausführen aller Tests benötigt werden.

Mit diesem Setup werden deine privaten benutzerdefinierten Module auf dieselbe Weise getestet wie die regulären Drupal-Module auf drupal.org, und wenn du außerdem wöchentlich geplante Pipelines konfigurierst, profitierst du von diesen regelmäßigen Tests auf dieselbe Weise.

Die Vorteile eines einheitlichen Ansatzes

Die Verwendung derselben Vorlage für öffentliche und private Module gewährleistet einen konsistenten und robusten Prüfablauf, unabhängig von Umfang und Status des Moduls.

Fazit

Ein ganzheitlicher Ansatz für die Entwicklung von Drupal-Modulen

In diesem Leitfaden haben wir uns darauf konzentriert, ein robustes Test-Framework für Drupal-Module zu entwickeln - sowohl für öffentliche als auch für private Module. Durch die Implementierung automatisierter wöchentlicher Tests und die Nutzung der CI/CD-Vorlagen von GitLab hast du ein leistungsfähiges System zur Sicherstellung von Codequalität, Kompatibilität und Stabilität geschaffen.

Ein Blick in die Zukunft - Testen von Abhängigkeiten auf einer echten Drupal-Site

Das Testen deiner Module ist jedoch nur ein Teil des Puzzles. Eine wirklich proaktive Entwicklung erfordert ein Echtzeit-Verständnis des Zustands deines Moduls in einer vollwertigen Umgebung. Hier kommt das Konzept der Referenzseiten ins Spiel.

Wenn du mehr über das Einrichten und Verwalten von Referenzseiten für die Echtzeitüberwachung und das Testen von Abhängigkeiten erfahren möchtest, lies bitte unseren Begleitartikel: Echte Drupal-Site-Abhängigkeitstests - ein strategischer Ansatz

Ressourcen und weiterführende Literatur

• GitLab CI-Vorlagen und ihre Dokumentation
• LakeDrops Private Modul CI/CD-Vorlage
• Real Drupal Site Dependency Testing - Ein strategischer Ansatz

Vielen Dank, dass du diesen Leitfaden durchgelesen hast! Wir hoffen, du hast wertvolle Einblicke und praktische Techniken zur Verbesserung deines Drupal-Modulentwicklungs-Workflows gewonnen.

Offenlegung: Ich habe das Gemma3 LLM in Ollama verwendet, um die Struktur aufzubauen und einige Inhaltsvorschläge zu erstellen, die auf meinem eigenen Verständnis des Problembereichs und der von uns implementierten Lösungen basieren. Außerdem habe ich Deepl und LanguageTools für die Verbesserung von Rechtschreibung und Grammatik verwendet. Das Schreiben des Artikels selbst betrachte ich als meine eigene Arbeit, und die KI war lediglich ein unterstützendes Werkzeug.