Einerseits gibt es viele gute Gründe eine Microservice-Architektur anzustreben, andererseits macht dieser Stil einige klassische QA-Prozesse schwieriger: Es gibt keinen großen Release-Kandidaten, der vor dem Live-Gang ausgiebig getestet werden könnte, kein zentrales Log-File, um nach Ursachen zu suchen und auch deutlich mehr als ein Team, dem man eventuelle Bugs zuweisen könnte. Statt dessen werden Services aktualisiert, während
Tests durchgeführt werden, es gibt genau so viele Log-Files wie Services und viele Teams, die ein Problem verursacht haben könnten.

Bei REWE digital haben wir als Antwort auf diese Herausforderungen einen QA-Ansatz gewählt, der vollständig durch die Teams getrieben wird. Wir haben eine Menge guter, aber auch schlechter Ideen an unserem Microservice Ökosystem ausprobiert. Sei es bei der Automatisierung von Tests, dem Monitoring von Services, dem Schreiben von Log-Files oder der Art wie wir mit Problemen (in Produktion) umgehen.

In meinem Vortrag werde ich einiger der besten und schlechtesten Maßnahmen erläutern und erklären, wie unser aktueller QA-Prozess (trotzdem) funktioniert.

Was lernen die Zuhörer in dem Vortrag?

Einige gute und einige schlechte Ideen, wie man in einem Microservice-Ökosystem Qualitätssicherung betreiben kann.