Startumgebung erstellen/Containerbau

Bei mir werden die Startumgebungen (die Infrastruktur: Webserver, Datenbankserver, Mailserver) in Docker-Containern vorgehalten, die größtenteils mit Docker Compose erstellt werden. Für manuelle Tests kann ich die Infrastruktur von Hand starten, doch meist verwende ich Jobs in Jenkins, um die Tests laufen zu lassen. Jenkins kann Umgebungsvariablen übermitteln und ruft in der Regel ein Script auf, in dem die Umgebung erst mal weiter präpariert wird (Headless Browser, Selenium starten, Video starten und stoppen, …). Außerdem habe ich hier die Tests einer Suite einzeln gelistet, damit ich sie auskommentieren und die Tests auf meine aktuellen Bedürfnisse zuschneiden und damit noch schneller machen kann.

Um Tests möglichst schnell zu halten, macht es Sinn, für die verschiedenen Kategorien an Tests auch verschiedene Startumgebungen vor zu halten.

Fixe Container

So braucht ein Integrationstest, der eben auch die Installation enthält, ein mehr oder weniger jungfräuliches Joomla. Hier werden Ordner, Dateien und Tabellen angelegt, verwendet und bei der Deinstallation auch wieder entfernt. Dafür wird eine komplett definierte Ausgangsumgebung benötigt, die bis auf Anpassungen, wenn es eine neue Version von Joomla gibt, nicht geändert wird. Ich habe für mich den Begriff fixe Container kreiert.

Flexible Container

Das Gegenstück sind flexible Container.

Meine Akzeptanztests werden - auch mangels vorhandener Unit- und Funktionstests - zum Debuggen der Erweiterung verwendet, also sollen sie besonders schnell sein. Hier werden nur Daten in den Tabellen modifiziert, also kann man theoretisch die Erweiterung installieren und daraus einen Container bauen. Aber ganz so einfach ist es dann doch nicht, denn während die Erweiterung debuggt wird, ändern sich ja deren Dateien! Dazu habe ich mir folgende Vorgehensweise überlegt:

1. Ich kopiere die Dateien der Infrastruktur für die Integrationstests, die ja für praktisch alle Erweiterung immer dieselbe ist. Besser: Einen Master (oder mehrere) anlegen, von denen die weiteren Container abgeleitet werden.
2. Ich lege neue Compose-Dateien für Infrastruktur und Tester an und passe sie an. Besser: ein Container mit Umgebungsvariablen an den richtigen Stellen. Schade, dass man in den Compose-Dateien nicht rechnen kann, dann wären die IP-Adressen flexibler… Vielleicht außerhalb in dem Script, das die Infrastruktur aufruft?
3. Ich passe die Konfigurationsdatei von Joomla an die neuen Gegebenheiten an. Das geht automatisiert wohl nur durch suchen und ersetzen
4. Ich starte diese neue Infrastruktur "von Hand", also ohne Job aus Jenkins heraus
5. Jetzt müssen in der Datenbank die neuen User angelegt oder die vorhandenen modifiziert werden.
6. Ich installiere die Erweiterungen, aktuell also das Paket von BwPostman und das Plugin Buyer2Subscriber, falls der Master "ohne" war.
7. Ich versorge BwPostman mit den Testdaten, falls der Master "ohne" war. Dafür gibt es eine dafür vorbereitete Sicherung aus BwPostman
8. Ich mache einen Dump der Datenbank. In diesem Dump muss angegeben sein, dass die Tabellen zuerst geleert und dann neu befüllt werden. Dieser Dump kann dann per Job wieder eingelesen werden, wenn es nötig werden sollte.
9. Die neue Infrastruktur muss als neue Umgebung in die Konfigurationsdatei acceptance.suite.yml aufgenommen werden. Einen sprechenden, aber kurzen Namen verwenden. Siehe auch nächster Punkt.
10. Das Startscript, das der Job aufruft, muss gegebenenfalls den Dump aus Schritt 6 wieder einspielen und jedes Mal die Dateien zwischen IDE und Test-Container synchronisieren. Dann muss das Startscript die Umgebungsvariable, die in Schritt 9 vergeben wurde, in die Tests einfügen. Nicht vergessen: Startscript ausführbar machen!

Damit habe ich eine Startumgebung mit installierter Erweiterung und allen Testdaten, die auf Änderungen während des Debuggens reagieren kann. Die Container verstehen leider keine Symlinks, was die noch schnellere und zuverlässigere Methode wäre, die beim Debuggen geänderten Dateien auch sicher in der Test-Umgebung zu haben.

Codeception und Jenkins  anpassen

Jede neue Testumgebung braucht auch einen Eintrag in der acceptance.suite.yml. Der hier vergebene Name wird in dem Script, das Jenkins aufruft (z.B. bwpm-b2s_job.sh) als TEST_ENV weiter gereicht. Damit weiß Codeception, welche Konfiguration zur Datenbank verwendet werden soll.

Der Job in Jenkins exportiert alle möglichen Umgebungsvariablen. Er prüft, ob die Datenbank wiederhergestellt werden muss. Dazu prüft er, ob die Datei /vhosts/dev/joomla-cms/tests/_output/failed vorhanden ist. Wenn ja, dann ist der vorige Test daneben gegangen und es ist nicht sicher, ob die Datenbank noch in einem sauberen Zustand ist. Normalerweise ist sie das, weil jeder einzelne Test am Ende aufräumt, also Abonnenten, User, Bestellungen oder was auch immer während des Laufs hinzugefügt/geändert wurde, wieder zurück setzt oder löscht.

Hier wird auch der grobe Rahmen der Tests bestimmt, also Einzeltests oder Gesamttests. Dann wird die Infrastruktur für die Tests gestartet, die Dateien werden synchronisiert und schließlich startet der Tester, der sein eigenes Script hat.