Startumgebung erstellen/Containerbau: Unterschied zwischen den Versionen
Romana (Diskussion | Beiträge) (→Flexible Container) |
Romana (Diskussion | Beiträge) (→Flexible Container) |
||
| Zeile 12: | Zeile 12: | ||
# Ich kopiere die Dateien der Infrastruktur für die Integrationstests, die ja für praktisch alle Erweiterung immer dieselbe ist | # Ich kopiere die Dateien der Infrastruktur für die Integrationstests, die ja für praktisch alle Erweiterung immer dieselbe ist | ||
| − | # Ich lege neue Dockerfiles und Compose-Dateien an | + | # Ich lege neue Dockerfiles und Compose-Dateien an und passe sie an |
| + | # Ich passe die Konfigurationsdatei von Joomla an die neuen Gegebenheiten an | ||
# Ich starte diese neue Infrastruktur von Hand | # Ich starte diese neue Infrastruktur von Hand | ||
# Ich installiere die Erweiterungen, aktuell also das Paket von BwPostman und das Plugin Buyer2Subscriber | # Ich installiere die Erweiterungen, aktuell also das Paket von BwPostman und das Plugin Buyer2Subscriber | ||
Version vom 20. April 2017, 13:37 Uhr
Bei mir werden die Startumgebungen und 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:
- Ich kopiere die Dateien der Infrastruktur für die Integrationstests, die ja für praktisch alle Erweiterung immer dieselbe ist
- Ich lege neue Dockerfiles und Compose-Dateien an und passe sie an
- Ich passe die Konfigurationsdatei von Joomla an die neuen Gegebenheiten an
- Ich starte diese neue Infrastruktur von Hand
- Ich installiere die Erweiterungen, aktuell also das Paket von BwPostman und das Plugin Buyer2Subscriber
- Ich versorge BwPostman mit den Testdaten. Dafür gibt es eine dafür vorbereitete Sicherung aus BwPostman
- Ich mache einen Dump der Datenbank. In diesem Dump muss angegeben sein, dass die Tabellen zuerst geleert und dann neu befüllt werden
- Ich lösche alle Ordner, die die Installation in Schritt 4 angelegt hat
- Ich lege Links auf die entsprechenden Ordner des Vhosts der Entwicklungsumgebung an
- das Startscript, das der Job aufruft, muss den Dump aus Schritt 6 wieder einspielen
Damit habe ich eine Startumgebung mit installierter Erweiterung und allen Testdaten, die auf Änderungen während des Debuggens reagieren kann.