QS im Spannungsfeld von DevOps + Kubernetes

Wenn agile Entwicklungsmethoden eingesetzt werden, deren Anspruch es ist, automatisierte Abläufe zu nutzen, stellt sich die Frage nach der QS. Wo und vor allem wie kommt sie ins Spiel? Denn auch hier besteht der Anspruch nach maximaler Automatisierung. Aber kann das überhaupt sinnvoll umgesetzt werden? 

DevOps

Laut Wikipedia versteht man unter DevOps eine Sammlung unterschiedlicher technischer Methoden und eine Kultur zur Zusammenarbeit zwischen Softwareentwicklung und IT-Betrieb. Durch gemeinsame Prozesse und Software-Werkzeuge soll eine effektivere und effizientere Zusammenarbeit der Bereiche Softwareentwicklung (Dev), Systemadministratoren (Ops) sowie Qualitätssicherung (QS) ermöglicht werden.

Ein idealer DevOps-Zyklus sieht so aus:

1. Entwicklung (Erstellen und Bereitstellen von beispielsweise Binärdateien, Skriptdateien, Container-Images usw. in einer QS-Umgebung)
2. Qualitätssicherung: Testfälle ausführen und schließlich
3. Bereitstellung in der Produktion
4. Betrieb
5. Überwachung
6. Planung (eines weiteren Releases)

Danach geht es wieder bei 1 los – man durchläuft eine Schleife.

Dieser Zyklus suggeriert, dass nur in Schritt 2 QS stattfindet. Das ist jedoch ein Trugschluss. Tatsächlich findet QS u. a. auch beim Build (Komponententests) oder auch beim Release statt.

Dabei wird großer Wert auf die Automatisierung von Build, Deployment und Testing gelegt. Durch die Verwendung von CI-Tools (Continuous Integration) werden Automatisierungstests somit zur Norm in einem DevOps-Zyklus.

Der Anspruch von maximaler Automatisierung ist jedoch problematisch, da nicht alle QS-Maßnahmen uneingeschränkt automatisierbar sind. Insbesondere BITV (Barrierefreiheit) oder nicht-funktionale Tests, wie Benutzerfreundlichkeit, bedürfen idealerweise menschlicher und somit manueller Verifikation.

Folge:
Der „eigentlich“ automatisierte DevOps-Zyklus muss für manuelle Aktivitäten unterbrochen und danach wieder angestoßen werden.

Docker + Kubernetes

Die Kernfunktionalität von Docker besteht in der Container-Virtualisierung von Anwendungen. Docker nutzt kein eigenes OS, sondern verwendet das Betriebssystem des Hosts. Mit Docker wird der Anwendungs-Code inklusive aller Abhängigkeiten in ein sogenanntes Image gepackt. Die Docker-Software führt die so verpackte Anwendung in einem Docker-Container aus. Images lassen sich zwischen Systemen bewegen und auf jedem System ausführen, auf dem Docker läuft.

Kubernetes (K8s) ist in diesem Zusammenhang ein Werkzeug für die Container-Orchestrierung (Kubernetes = [griechisch] Steuermann). Mit Orchestrierung ist eine effiziente sowie automatisierte Verwaltung, Bereitstellung, Überwachung und Skalierung von Systemen für containerisierte Anwendungen gemeint.

Container-Virtualisierung (Docker) in Kombination mit Kubernetes berücksichtigt den technologischen Trend weg von monolithischen Client-Server-Anwendungen, mit schwergewichtigen Applikations- und Datenbank-Servern. Obgleich auch diese Anwendungen skalierbar waren und man auf Ausfälle automatisiert reagieren konnte, ist das durch Containerisierung und der damit verbundenen Unterteilung einer Anwendung in deutliche kleinere Teile viel einfacher, effektiver und ressourcenschonender geworden.

DevOps + Kubernetes (Docker) + QS

Das methodische Vorgehen nach DevOps und Kubernetes’ Technologie ergänzen sich in der agilen Softwareentwicklung ideal. Es stellt jedoch auch eine neue Herausforderung an die Qualitätssicherung dar. In klassischen Projekten, die nach dem Wasserfallmodell, oder besser dem V-Modell, gearbeitet haben, war der „Platz“ für QS eindeutig definiert. Auf agilen Pfaden wie DevOps spielt die QS von Anfang an eine Rolle und bleibt permanent präsent. Meist automatisiert, aber auch manuell. Speziell wenn Backend-Tests ins Spiel kommen, wird es besonders herausfordernd, denn dazu müssen unterschiedliche Container adressiert und separat oder im Zusammenspiel getestet werden. 

Fazit

Reines End-to-End Testen oder Oberflächentests waren gestern. Bei agilen Softwaremethoden setzte QS schon viel früher und immer wieder ein. Dazu gehört auch das Umfeld des Komponententests, der eigentlich die Domäne der Entwicklung ist. Denn ein psychologischer Nachteil besteht immer, wenn die Entwicklung allein testet – Entwickler wollen die Richtigkeit Ihres Codes bestätigt wissen. Tester wollen dagegen Fehler finden. Daraus resultieren unterschiedliche Herangehensweisen und somit auch unterschiedliche Ergebnisse. Somit ist es sinnvoll, dass sich Entwicklung und Qualitätssicherung gegenseitig und frühzeitig unterstützen. 

Seminarempfehlung