Startumgebung erstellen/Containerbau: Unterschied zwischen den Versionen

(Keine Zusammenfassung)
 
Zeile 1: Zeile 1:
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 einzelnen Tests einer Suite
+
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. So braucht ein Integrationstest, der eben auch die Installation enthält, ein mehr oder weniger jungfräuliches Joomla. Meine Akzeptanztests werden - auch mangels vorhandener Unit- und Funktionstests - zum Debuggen der Erweiterung verwendet, also sollen sie besonders schnell sein. Hierfür bietet sich
+
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
 +
* 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
  
 
[[Kategorie:Testing]]
 
[[Kategorie:Testing]]

Version vom 20. April 2017, 10:31 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
  • 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