20170526-JavaSpektrum-Microservces-testautomation-1

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
Petri Heil!
Testautomation einer
Microservice-
Architektur – Teil 1
Rudolf Grötz, Dominik Kukacka, Nebojsa Nikolic
IntegrationsSpektrum
In Zeiten der Digitalisierung ist es für dynamische Unternehmen notwendig,
technische Strukturen zu etablieren, die den immer schneller
werdenden Marktanforderungen gerecht werden. Der digitale Darwinismus
fordert Strukturen, die sowohl agil als auch schnell genug sind,
diesen Anforderungen gerecht zu werden.
Charles Darwin hat in seinen Werken einen wichtigen
E Punkt erarbeitet: Es sind nicht die Stärksten, die überleben,
und auch nicht die Intelligentesten. Es sind vielmehr jene,
die sich am schnellsten den neuen Gegebenheiten anpassen
können.
Microservices als Antwort auf den digitalen
Darwinismus
Unternehmen wie Netflix, Amazon und Google haben schnell
erkannt, die notwendigen technischen Strukturen anzupassen
und zu implementieren. Geschafft wurde das durch den Einsatz
von Microservices als neues Architekturprinzip. Weg vom
Monolithen, hin zu kleinen, schlanken, unabhängigen Services,
die über standardisierte APIs kommunizieren. Statt einer
einzelnen monolithischen Anwendung, die die gesamte Geschäftslogik
enthält, erledigt ein flexibles Netzwerk aus Microservices
alle komplexen Vorgänge.
In dieser 2-teiligen Artikelserie gehen wir auf die Entwicklung
einer mobilen Anwendung ein. Diese basiert auf einer
Microservice-Architektur, die innerhalb einer Docker basierten
Systemumgebung abläuft.
Wir widmen uns der Entwicklung der Microservices mit
NODE.JS und Python sowie der Orchestrierung dieser Services
mit Docker Images und Docker Container. Schließlich zeigen
wir auf, wie diese Microservices innerhalb einer Continuous
Delivery Pipeline* automatisiert getestet werden, um sicherzustellen,
dass die Dienste wie erwartet funktionieren.
* Ein Wort in eigener Sache: Um die Lesbarkeit dieses Artikels zu erhöhen, werden
englische Fachbegriffe nur übersetzt, sofern es möglich ist und nicht zu Missverständnissen
oder Unworten führt. Es wird also aus einer Continuous Delivery Pipeline
niemals eine Kontinuierliche Lieferungsrohrleitung und aus einem Consumer
Contract nie ein Verbrauchervertrag, aber aus einem Testcase durchaus ein Testfall.
Microservices
Der Trend in der Systemarchitektur geht weg vom Monolithen,
hin zu Microservices, um durch kleine überschaubare Programmeinheiten
Continuous Delivery zu ermöglichen und Features
schneller dem Markt zur Verfügung stellen zu können.
Microservices ist ein Architekturmuster, bei dem die Anwendung
in Services unterteilt wird und nicht in Schichten (s.
Abb. 1). Die Microservices sind dabei entkoppelt und laufen in
einem eigenen Prozess, damit diese leichter austauschbar sind.
JS-3-17 – grötz – k1
Microservices sind auch technologisch voneinander unabhängig,
da sie durchaus mit verschiedenen Programmiersprachen,
Frameworks oder Datenbanken realisiert werden können.
Martin Fowler bezeichnet „Microservices“ als „yet another
new term on the crowded streets of software architecture” [Fow14].
Sie lassen sich unter anderem durch folgende Eigenschaften
beschreiben:
Abb. 1: Architekturmuster
H Die Anwendung wird in kleine Services unterteilt, die entkoppelt
sind, und verwendet diese als Komponenten. Diese
Services sind IT-Repräsentationen von in sich abgeschlossenen
fachlichen Funktionalitäten.
H Microservices enthalten alle Schichten (Datenbank, Middleware
und Frontend) einer Funktionalität. Anwendungen
werden somit nicht in Schichten unterteilt, sondern in Funktionalitäten.
H Microservices werden eigenständig und nicht als gesamte
Anwendung deployed. Dadurch entsteht selbst bei der Implementierung
keine Abhängigkeit zu anderen Services.
H Die Kommunikation von Microservices erfolgt meist über
HTTP-basierte Schnittstellen, wie beispielsweise RESTful-
APIs.
Die Idee von Microservices entspricht der Unix-Philosophie
„Schreibe Computerprogramme so, dass sie nur eine Aufgabe
erledigen und diese gut machen.“ [Wiki]
Anforderung mobiler Anwendungen
Die Einführung einer auf Microservices basierenden Architektur
bedarf einiger spezifischer Überlegungen, wenn es darum
geht, die Inhalte für mobile Anwendungen zur Verfügung zu
stellen. Die wichtigste, die Performanz, werden wir in diesem
Artikel auch berücksichtigen.
Webanwendungen werden in der Regel auf Geräten ausgeführt,
die über WLAN oder Ethernet mit dem Internet verbunden
sind, also mit geringer Latenz. Mobile Geräte verbinden
sich oft über 3G, Edge oder auch GPRS, also mit hoher Latenz.
Daher ist es gerade bei solchen Verbindungen wichtig, die Anzahl
der Aufrufe über das Netzwerk gering zu halten.
Da die Anzahl der Aufrufe wachsen kann, trägt jede HTTP-
Transaktion in der Gesamtreaktionszeit zu einem exponentiellen
Wachstum bei. Daher ist es ratsam, hier einen eigenen
Microservice – ein API Gateway [NGINX] – zur Verfügung
zu stellen, der die Daten aller Zugriffe sammelt und in einer
Transaktion an die aufrufende Anwendung übergibt.
Beispiel einer mobilen Microservice-Landschaft
In vorherigen Abschnitt führten wir den Begriff Microservice
ein und präsentierten einige Überlegungen für mobile Anwen-
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
www.javaspektrum.de 1

IntegrationsSpektrum
JS-3-17 – grötz – k1
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
dungen. Nun werfen wir einen Blick auf die Entwicklung von
Microservices. Das Ganze am Beispiel einer mobilen Anwendung
für Hobby-Angler.
Die Probleme eines Hobby-Anglers
Es ist ein großer Vorteil für Angler zu wissen, wann die Sonne
auf und wann die Sonne untergeht. Warum? Weil auf manchen
Gewässern das Nachtfischen verboten ist. Nun stellt sich die
Frage, von wann bis wann ist es eigentlich Nacht? Die Antwort
steht im Fischereigesetz: eine Stunde nach Sonnenuntergang
bis eine Stunde vor Sonnenaufgang. Daher muss man wissen,
wann die Sonne auf und untergeht.
Dann gibt es ja auch noch die Wetterfrage.
Was zieht der Angler an? Welche
Kleidung muss berücksichtigt werden?
Überrascht mich wieder das Wetter und
ich muss den Anglertrip abbrechen?
All diese Fragen beantwortet unsere mobile
App SunRiseSet (s. Abb. 2). Sie liefert
für einen eingegebenen Ort den Sonnenauf-
und Untergangszeitpunkt, die Wetterdaten
und die Landkarte. Ausgehend von
den Millionen von registrierten Fischereikartenbesitzern
(und noch mehr Schwarzfischern),
wird diese App sicher ein großer
Erfolg. Aus diesem Grund müssen sich Benutzer
registrieren, damit wir mit den Kundendaten
Geld verdienen können.
Abb. 2: Startscreen Soweit die Theorie. Doch beschäftigen
der App
wir uns nun mit der Praxis: der Microservice-Architektur,
die alle diese Daten ermittelt,
speichert und zur Verfügung steht.
SunRiseSet – Microservice-Architektur
Unser System besteht auf der Backend-Seite aus sechs Microservices,
die in Docker-Containern laufen. Der Location-
Service und der Weather-Service greifen auf externe APIs zu.
Die Services sind ein Mix aus NODE.JS und Python und haben
folgende Funktionalitäten:
H API-Gateway dient als Facade. Nur über dieses Gateway
kann auf die dahinterliegenden Service zugegriffen werden.
H Auth dient zu Authentifizierung des User und der Tokenverwaltung.
H MariaDB dient zum Persistieren der Userdaten.
H Location dient zur Ermittlung der Geolocation via externen
Webservice.
H Weather ermittelt die Wetterdaten für die Geolocation via
externen Webservice.
H Sun berechnet Sonnenauf- und Sonnenuntergang für die
Geolocation.
Jedes Service läuft in einem eigenen Docker-Container und
liefert JSON zurück.
Ablauf
Das API-Gateway nimmt Anfragen von Clients (Mobile und
Web) entgegen, führt die Authentifizierung durch und greift
auf die dahinterliegenden Services zu. Abbildung 3 enthält das
Komponentendiagramm, das Sequenzdiagramm in Abbildung
4 zeigt die Details des Login-Vorgangs.
Abb. 3: Übersicht der Docker-Container & Microservices
Abb. 4: Login-Vorgang
Der Login-Service
Unser erster Microservice ist für das Login über das API-Gateway
zuständig. Er besteht gerade mal aus 23 Zeilen (20 ohne
Leerzeilen) NODE.JS-Code, verwendet Port 8080, HTTP und
liefert JSON zurück.
20 Zeilen Code – in Österreich würde man sagen „Ned
schlecht Herr Specht“, oder anders ausgedrückt „Gut gemacht,
bemerkenswert!“
Zur Vereinfachung werden wir uns im Folgenden nur um
diesen Microservice kümmern. Das gesamte Projekt finden Sie
auf GitHub [GitLab]. Wir werden keine Zeit damit verbringen,
den Code der Microservices zu diskutieren.
var express = require('express');
var request = require('request');
var cors = require('cors');
var app = express();
app.use(cors());
app.get('/login', function(req, res) {
request('http://auth:8080/token?username=' + req.query.username +
'&password=' + req.query.password, function(err1, r1, data) {
var _data = {};
try {
var _data = JSON.parse(data);
if(_data.success === true) {
return res.send(_data);
} else {
return res.status(403).send(_data)
}
} catch(e) {
console.error('could not parse auth response', e);
return res.sendStatus(500);
}
});
});
Listing 1: Authentication-Service
Der Aufruf des Service im Browser via
http://localhost:8000/login?username=rgroetz&password=test123
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
2
JavaSPEKTRUM 3/2017

IntegrationsSpektrum
JS-3-17 – grötz – k1
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
sollte folgenden JSON-String zurück liefern:
{"success":false,"errorCode":4000,"message":"invalid credentials"}
Momentan aber liefert der Aufruf noch die Fehlermeldung:
localhost refused to connect.
zurück, da die Services noch nicht in den Docker-Containern
laufen. Zu Docker und wie wir die Microservice-Architektur
zum Laufen bringen, kommen wir im nächsten Abschnitt.
Dockerized Microservice – Build, Ship, Run
Im Vergleich zu klassischen monolithischen Anwendungen
sind die einzelnen Mikroservices für sich gesehen jeweils nicht
sonderlich komplex (siehe 20 Zeilen Code). Einen großen Overhead
bringt jedoch die für die Mikroservices benötigte Infrastruktur
mit sich. Anstatt einer Systemumgebung (Application
Server, Datenbank, …) für die gesamte Anwendung muss für
jeden Microservice eine eigene Systemumgebung installiert,
konfiguriert und betreut werden.
Mit Docker [Tie15] können die einzelnen Microservices inklusive
der benötigten Abhängigkeiten in leichtgewichtige
Container gepackt werden. Docker macht es einfach, die Software
zu paketieren, zu verteilen und auszuführen. Mit Docker
können Tests im Container ausgeführt und in verschiedensten
Umgebungen isoliert getestet werden.
Zusammen mit Cloud-Plattformen besteht jetzt eine einfache
Möglichkeit, das Testen auf mehreren Plattformen vorhersehbar
zu machen. Dies gibt das Vertrauen, das, wenn etwas
auf einer Systemumgebung funktioniert, es auch in der Produktionsumgebung
funktioniert. Die Aussage „Works on my
machine!“ bekommt dadurch gleich wieder eine andere Bedeutung.
Erstellung eines Docker Image
Ein Docker Image ist ein Softwarepaket, bestehend aus allen
Abhängigkeiten und deren Binärdateien. Der Start eines Docker
Image instanziiert einen Docker Container, welcher dann
eine komplette Laufzeitumgebung, wie vom Ersteller des
Image definiert, zur Verfügung stellt.
Anhand eines Dockerfile, welches alle Kommandos enthält,
die zum Bau des Image notwendig sind, kann die Erstellung
des Docker Image automatisiert werden. Listing 2
zeigt das Dockerfile für unser Image, das in weiterer Folge
die Laufzeitumgebung für den Login-Microservice zur Verfügung
stellt.
FROM node:6.9-alpine
COPY ./src /data
WORKDIR /data
RUN npm install && \
npm cache clean && \
rm -rf /tmp/*
EXPOSE 8080
CMD ["node", "server.js"]
Listing 2: Das Dockerfile
Das Dockerfile aus Listing 2 weist Docker an:
H Baue das Image initial mit einem NODE.JS 6.9 Image.
H Kopiere das Verzeichnis ./src/data in das aktuelle Image-
Verzeichnis.
H Definiere /data im Image als das Arbeitsverzeichnis.
H Installiere die NODE.JS-Applikation (unser Microservice)
aus dem Arbeitsverzeichnis.
H Mache Port 8080 nach außen verfügbar.
H Starte die Applikation server.js (unser Microservice).
Mit dem Docker-Kommando:
$ docker build -t facade-login .
starten wir den Bau des Docker Image im lokalen Arbeitsverzeichnis.
Mit Parameter -t geben wir dem Image einen Namen.
So, jetzt haben wir ein Docker Image, das wir in weiterer Folge
zu einem Docker Container machen und in unsere Registry
(registry.gitlab.com/devopsbusters) hochladen und dann für unser
Docker-Compose brauchen. Zur Vereinfachung werden wir
uns nur um den Bau dieses Docker Image in diesem Artikel
kümmern.
Start eines Docker-Containers
Die Schritte, die zum Installieren und Starten eines Mikroservice
in einem Docker-Container notwendig sind, werden über
eine Docker-Compose-Datei automatisiert. So ist es mit Docker-Compose
möglich, die Erstellung der Images zu automatisieren,
und die Erstellung von Docker-Containern kann in jedes
Build-Tool integriert werden.
Die Aufgabe von Docker-Compose ist das Management einer
Gruppe von Docker-Containern. Die Deklaration einer
Gruppe wird in der Datei docker-compose.yml abgelegt. Mit
dem Werkzeug können nun einzelne Container oder Gruppen
erzeugt, verwaltet und gestartet werden.
Eine detaillierte Einführung in Docker, seine Tools und sein
Build-, Ship-, Run-Konzept finden Sie hier: www.docker.com/.
Listing 3 zeigt die Docker-Compose-Datei unserer Microservice-Landschaft.
version: '2'
services:
sun:
build: ../service-sun
image: registry.gitlab.com/devopsbusters/service-sun:master
ports:
- "8001:8080"
location:
build: ../service-location
image: registry.gitlab.com/devopsbusters/service-location:master
ports:
- "8002:8080"
weather:
build: ../service-weather
image: registry.gitlab.com/devopsbusters/service-weather:master
ports:
- "8003:8080"
auth:
build: ../service-auth
image: registry.gitlab.com/devopsbusters/service-auth:master
ports:
- "8004:8080"
login:
build: ../facade-login
image: registry.gitlab.com/devopsbusters/facade-login:master
ports:
- "8005:8080"
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
www.javaspektrum.de 3

IntegrationsSpektrum
JS-3-17 – grötz – k1
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
links:
- auth
api:
build: ../facade-api
image: registry.gitlab.com/devopsbusters/facade-api:master
ports:
- "8000:8080"
links:
- auth
- sun
- location
- weather
Listing 3: Docker-Compose-Datei
Mit dem Befehl:
docker-compose build
bauen wir die Container für unserer Microservice-Umgebung.
Mit dem Befehl:
docker-compose up -d
werden die Container gestartet und die Services zur Verfügung
gestellt.
Up & Running?
So, die Microservices sind codiert, die Docker Images gebaut,
die Microservices laufen in den Docker-Containern. So unsere
Vermutung. Doch stimmt unsere Vermutung? Mit:
docker ps
prüfen wir, welche Docker-Container gestartet sind. Und siehe
da, sechs Microservices laufen wie definiert (s. Abb. 5).
Abb. 5: Die laufenden Microservices
Nun prüfen wir noch auf leichte Art und Weise via Browser,
dass die Services laufen und korrekt zusammenarbeiten:
http://localhost:8005/login?username=rgroetz&password=test123
Und siehe da, unsere Microservices laufen (s. Abb. 6)! Im Gegensatz
dazu liefert der Aufruf mit einem gültigen User folgende
JSON-Nachricht zurück (s. Abb. 7).
Nachdem wir unsere Services nicht immer manuell testen
wollen, kümmern wir uns jetzt um automatisierte Tests, die in
unserer Continuous Delivery Pipeline [Fow13] laufen sollen.
Testen von Microservices
Eine Microservice-Architektur besteht aus unabhängig einsetzbaren
Diensten, die es erschweren, nur altbekannte Testansätze
in der Pipeline anzuwenden.
Durch das Zerteilen eines Systems in kleine, eigenständige
Services werden zusätzliche Schnittstellen sichtbar, die in einer
Abb. 6: Login-Versuch mit ungenügenden Berechtigungen
Abb. 7: Login-Versuch mit ausreichenden Berechtigungen
monolithischen Architektur nicht vorhanden waren. Zusätzliche
Schnittstellen, nicht nur in technischer, sondern auch in
organisatorischer Hinsicht, sind hilfreich, sind doch nun meistens
mehrere Teams an der Entwicklung beteiligt.
Die Zusammenarbeit mehrerer Services, sowohl aus Consumer-
als auch Provider-Sicht, und die reibungslose Integration
der Services untereinander sind daher ein wichtiger Aspekt.
Diesem Umstand wird durch zusätzlichen Tests, besser bekannt
unter dem Begriff „Consumer-Driven Contracts“, begegnet.
In der Welt der Softwaretests gibt es viele Bezeichnungen
für die verschiedensten Arten von Tests. Eine strikte Trennung
nach Zielen und Methoden ist sehr schwer. Das ISTQB-Glossar
[ISTQB] alleine unterscheidet fünf verschiedene Arten von
Acceptance-Tests. Diverse Testpyramiden, verschiedenster
Testspezialisten [Scott, Ash14] tragen nicht dazu bei, hier Unklarheiten
auszuräumen. Zum Test von Microservice-Umgebungen
sollten unserer Meinung nach folgende Tests Anwendung
finden.
Komponententests
Unit- oder Komponententests sind immer noch anwendbare
Testansätze, denn innerhalb seiner Grenzen ist jeder Service noch
sehr zusammenhängend. Diese Tests durchlaufen kleine Code-
Abschnitte, also Klassen oder Methoden. Abhängige Komponenten
werden dabei durch Mocks ersetzt, um den Service in einer
isolierten Umgebung unabhängig testen zu können.
Integrationstests
Durch die zusätzlichen Schnittstellen werden Integrationstests
noch wichtiger für das Gesamtgefüge. Wurden bisher die Daten
innerhalb eines Monolithen ausgetauscht, kommt durch
Microservices der Datenaustausch, in den meisten Fällen via
HTTP, ins Spiel. Die Integrationstests sollen sicherstellen, dass
dieses Zusammenspiel funktioniert.
Consumer-Driven Contracts
H it Consumer-Driven Contracts (CDC) ist ein fast vergessener
Testansatz wieder in den Mittelpunkt gerückt.
Thoughtworks hat aufgrund des Microservice-Hypes Consumer
Driven Contracts wieder auf den Technology Radar
[ThoughtWorks] zurückgeholt:
„… We’ve decided to bring consumer-driven contract testing back
from the archive for this edition even though we had allowed it to
fade in the past. The concept isn’t new, but with the mainstream
acceptance of microservices, we need to remind people that consumerdriven
contracts are an essential part of a mature microservice testing
portfolio, enabling independent service deployments …“
Consumer-Driven Contracts betrachten Microservices aus
der Perspektive der aufrufenden Einheit. Der Contract beschreibt,
wie die Antwort des Providers aufgebaut sein muss.
Im Grunde genommen definiert der Consumer eines Service
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
4
JavaSPEKTRUM 3/2017

IntegrationsSpektrum
JS-3-17 – grötz – k1
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
zusammen mit dessen Provider einen Kontrakt und prüft in
einem Test, ob dieser eingehalten wird. Stellt der Provider nun
eine neue Version des Service zur Verfügung, stellt er durch
den Contract-Test aller Consumer sicher, dass alle Serviceaufrufe
der Consumer noch funktionieren.
End-to-End-Tests
End-to-End-Tests kommen zum Einsatz, um die volle Qualität
des Systems zu gewährleisten. Diese Tests prüfen, ob die
Geschäftsfälle, wie sie ein Anwender durchführt, das richtige
Ergebnis liefern. Es wird dabei sichergestellt, dass Systemabhängigkeiten
und Datenintegrität zwischen verschiedenen
Systemkomponenten und Systemen beibehalten werden.
Lasttests
Lasttests sind eine Unterkategorie von Performanztests und prüfen,
ob die Leistung der Software unter ungünstigen und extremen
Bedingungen zufriedenstellend ist. Diese Bedingungen
können als Folge von starkem Netzwerkverkehr, Prozessorauslastung
oder Überlastung einer bestimmten Ressource auftreten.
Fazit
Der Trend in der Systemarchitektur geht weg vom Monolithen,
hin zu Microservices, um durch kleine überschaubare
Programmeinheiten Continuous Delivery zu ermöglichen und
Features schneller dem Markt zur Verfügung stellen zu können.
Durch das Zerteilen eines Systems in kleine, eigenständige
Services werden zusätzliche Schnittstellen sichtbar, die in einer
monolithischen Architektur nicht vorhanden waren. Diesem
Umstand muss mit altbekannten und neuen Arten von Tests
innerhalb der Continuous Delivery Pipeline begegnet werden.
Im nächsten Teil dieser Artikelserie widmen wir uns dieser Herausforderung
und gehen näher auf die Implementierung dieser
automatisierten Tests ein.
Links
[Ash14] St. Ashman, Post, 28.12.2014,
http://qa-matters.com/2014/12/28/layers-of-test-automation/
[Fow13] https://martinfowler.com/bliki/DeploymentPipeline.html
[Fow14] https://martinfowler.com/articles/microservices.html
[GitLab] https://gitlab.com/devopsbusters
[ISTQB] https://www.astqb.org/glossary
[NGINX] API-Gateway Pattern, https://www.nginx.com/blog/
building-microservices-using-an-api-gateway/
[Scott] Blog von A. Scott,
https://watirmelon.blog/tag/testing-pyramid/
[ThoughtWorks] https://www.thoughtworks.com/radar/techniques/
consumer-driven-contract-testing
[Tie15] F. Tiersch, Docker – Teil 1, 17.8.2015,
https://www.ab-heute-programmieren.de/docker-teil-1-was-ist-docker/
[Wiki] https://de.wikipedia.org/wiki/Unix-Philosophie
Rudolf Grötz, seit 30 Jahren in der IT unterwegs
und passionierter Softwaretester, ist seit 2016 als
Testarchitect/Technical Test Analyst bei s-ITSolutions in
Wien im Bereich Softwaretests tätig und lebt den Leitspruch
„Testautomation is not an act, Testautomation
is a habit!“ Neben Fachartikeln in diversen Magazinen
versorgt er die Community auch mit Konferenzauftritten
und organisiert das Vienna Agile Testautomation
Meetup. E-Mail: rudolf.groetz@gmail.com
Dominik Kukacka, bekennender „Clean Coder“,
entwickelt schon seit seiner frühesten Kindheit mit
Begeisterung Software. Seit 2015 verantwortet er als
CTO bei apilayer in Wien die Planung und Umsetzung
der kompletten Service-Landschaft.
Nebojsa Nikolic ist seit mehr als 20 Jahren als
Oracle-DBA und Systemadministrator tätig. Seit 2016
bei SVC designing E-Health in Wien angestellt, gehört
es dort zu seinen Aufgaben, Microservices und Virtualisierung
voranzutreiben, um dem DevOps-Gedanken
gerecht zu werden. Privat ist er leidenschaftlicher
Angler.
Die Meinung in diesem Artikel ist die Meinung der Autoren und
gibt nicht unbedingt die Meinung deren Arbeitgeber wieder!!!
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
www.javaspektrum.de 5