Startumgebung erstellen/Containerbau - Versionsgeschichte

Romana am 29. April 2017 um 10:26 Uhr

2017-04-29T10:26:53Z

Romana: /* Flexible Container */

2017-04-28T09:05:35Z

‎Flexible Container

Romana: /* Flexible Container */

2017-04-28T08:58:31Z

‎Flexible Container

Romana am 28. April 2017 um 07:58 Uhr

2017-04-28T07:58:11Z

Romana: /* Codeception und Jenkins anpassen */

2017-04-27T19:34:47Z

‎Codeception und Jenkins anpassen

Romana: /* Codeception anpassen */

2017-04-27T19:34:33Z

‎Codeception anpassen

Romana: /* Flexible Container */

2017-04-27T19:25:56Z

‎Flexible Container

Romana: /* Flexible Container */

2017-04-21T06:38:09Z

‎Flexible Container

Romana: /* Flexible Container */

2017-04-21T06:37:28Z

‎Flexible Container

Romana: /* Flexible Container */

2017-04-20T13:26:19Z

‎Flexible Container

@@ Zeile 11: / Zeile 11: @@
 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. '''Besser:''' Einen Master (oder mehrere) anlegen, von denen die weiteren Container abgeleitet werden.
 # 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?
 # Ich passe die Konfigurationsdatei von Joomla an die neuen Gegebenheiten an. Das geht automatisiert wohl nur durch suchen und ersetzen
@@ Zeile 31: / Zeile 31: @@
 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.
 [[Kategorie:Testing]]

@@ Zeile 11: / Zeile 11: @@
 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. '''Besser:''' Einen Master (oder mehrere) anlegen, von denen die weiteren Container abgeleitet werden.
-# Ich lege neue Compose-Dateien für Infrastruktur und Tester an und passe sie an
+# 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?
-# Ich passe die Konfigurationsdatei von Joomla an die neuen Gegebenheiten an
+# Ich passe die Konfigurationsdatei von Joomla an die neuen Gegebenheiten an. Das geht automatisiert wohl nur durch suchen und ersetzen
-# Ich starte diese neue Infrastruktur von Hand
+# Ich starte diese neue Infrastruktur "von Hand", also ohne Job aus Jenkins heraus
-# Falls noch nicht geschehen: Spätestens jetzt muss in der Datenbank der neue User angelegt werden.
+# Jetzt müssen in der Datenbank die neuen User angelegt oder die vorhandenen modifiziert werden.
-# 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, falls der Master "ohne" war.
-# Ich versorge BwPostman mit den Testdaten. Dafür gibt es eine dafür vorbereitete Sicherung aus BwPostman
+# Ich versorge BwPostman mit den Testdaten, falls der Master "ohne" war. 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 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.
 # 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.
-# Das Startscript, das der Job aufruft, muss 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 eingefügt werden. '''Nicht vergessen: Startscript ausführbar machen!'''
+# 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.

@@ Zeile 11: / Zeile 11: @@
 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 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.
 # Ich lege neue Compose-Dateien für Infrastruktur und Tester an und passe sie an
 # Ich passe die Konfigurationsdatei von Joomla an die neuen Gegebenheiten an
@@ Zeile 22: / Zeile 22: @@
 # Das Startscript, das der Job aufruft, muss 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 eingefügt werden. '''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==

← Nächstältere Version		Version vom 28. April 2017, 07:58 Uhr
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 Tests einer Suite einzeln gelistet, damit ich sie auskommentieren und die Tests auf meine aktuellen Bedürfnisse zuschneiden und damit noch schneller machen kann.	+	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.		Um Tests möglichst schnell zu halten, macht es Sinn, für die verschiedenen Kategorien an Tests auch verschiedene Startumgebungen vor zu halten.

@@ Zeile 27: / Zeile 27: @@
 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.
+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.
 [[Kategorie:Testing]]

← Nächstältere Version		Version vom 27. April 2017, 19:25 Uhr
Zeile 24:		Zeile 24:
	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.		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 anpassen==
	[[Kategorie:Testing]]		[[Kategorie:Testing]]