BSI Lab: Datenbank-Testautomatisierung mit Docker

Manchmal wird die Fehlerfindung in Projekten zur Suche nach dem Käfer im Heuhaufen. Da Tests auf der gleichen Datenbank laufen, werden an sich unabhängige Tests unnötig miteinander gekoppelt. Um die eigentliche Ursache eines fehlschlagenden Tests zu finden, geht dadurch viel Zeit verloren. Dieser Umstand motivierte uns, an unserem BSI Lab-Day zu prüfen, ob wir Tests mittels Docker effizient entkoppeln können.

  • Die Mission: Entkoppeln, was fundamental unabhängig sein muss.
  • Die Methodik: Das Potenzial nutzen, das in unseren modernen Build-Tools steckt.
  • Der Mehrwert: Wir eliminieren unnötige Fehlerquellen und schalten das Potenzial perfekter Parallelisierung frei – Welcome to the next level.

Die Mission unseres BSI Labs

Unsere Tests werden wie üblich auf einem Build-Slave per Maven aufgerufen und laufen nach einem initialen Datenbank-Reset alle nacheinander. Daher ist es möglich, dass ein Test A korrupte Daten hinterlässt, worauf ein Test B fehlschlägt. Wenn viele Tests vor Test B laufen – und vielleicht nicht einmal in einer festen Reihenfolge – wird die Fehlerfindung zur Suche nach dem Käfer im Heuhaufen. Dies kostet viel Zeit. Das fundamentale Problem ist, dass wir Prozesse, die komplett unabhängig voneinander laufen sollten, über eine gemeinsame Datenbank koppeln. Daher war es das Ziel unseres BSI Lab-Projekts zu prüfen, ob wir mittels Docker die einzelnen Tests entkoppeln und auf einer sauberen Datenbank ausführen können, ohne den Aufwand ins Unermessliche steigen zu lassen. Gleichzeitig wird damit der Grundstein zu einer nahezu vollständigen Parallelisierung gelegt.

Unser Vorgehen

Ausgehend von unserem aktuellen Test-Setup haben wir zuerst einen Proof of Concept erstellt, der die Tests entkoppelt auf einer sauberen Datenbank laufen lässt. Dies bedeutet:

  1. Es wird ein Docker-Image erstellt, in welchem eine frisch zurückgesetzte Datenbank zur Verfügung steht.
  2. Aus diesem Image wird für jeden Test ein eigener Docker-Container erzeugt, in dem der Test durchgeführt wird.
  3. Die Testergebnisse werden zusammengefasst.

Da dieser Proof of Concept sehr viel länger als unsere bestehende Pipeline braucht, um alle Tests auszuführen, haben wir anschliessend Möglichkeiten gesucht, den Overhead zu reduzieren. Dabei haben wir insbesondere zwei grosse Optimierungspotenziale geprüft:

  1. Ist es nun möglich, die Ausführung der Tests fast komplett zu parallelisieren?
  2. Lässt sich deutlich Rechenarbeit sparen, wenn die Ausführung der Tests nicht naiv mit einem kompletten Maven-Build durchgeführt wird, sondern tatsächlich nur einzelne Tests angestossen werden?
So sieht eine ausgelastete Maschine aus: Vier Tests parallel auf einem Laptop ausgeführt – halbe Laufzeit pro Test.

Mission accomplished?

Mit Docker, Maven und Kubernetes haben wir alle nötigen Bausteine, um die Ausführung unserer Tests entkoppeln und parallelisieren zu können. In unserem BSI Lab-Projekt wurde ein simpler Proof of Concept erarbeitet und verschiedene Möglichkeiten zur Optimierung aufgezeigt. Der zusätzliche Rechenaufwand ist mit der vorgestellten naiven Herangehensweise beträchtlich, es gibt aber noch viel Potenzial, ihn zu reduzieren. Die wichtigste Voraussetzung, die uns zum Praxiseinsatz fehlt, ist ein gemeinsamer Rechencluster, der die Tests tatsächlich auch parallel ausführen kann. Genügend Rechenkraft vorausgesetzt, sollten Ausführungszeiten kompletter Testpipelines in maximal 15 Minuten möglich sein – unabhängig von der Anzahl Tests.

Durch entkoppelte Tests können wir produktiv arbeiten, statt Zeit mit der Fehlersuche zu vergeuden. Mit einer schnelleren Pipeline werden wir wesentlich agiler. Die benötigte Zeit vom neuen Feature auf dem Entwickler-Rechner zum Review der Ergebnisse durch den Kunden reduziert sich. Dies führt zu einer effizienteren Zusammenarbeit.

Datum
Autor
Simon Greuter & Ivan Motsch