Quality assurance of a 200+ microservices system can not be centralized but needs to happen within the team, utilizing its expertise and creativity
While the Microservice architectural style has a lot of benefits, it makes certain QA practices impractical: there is no big release candidate that can be tested before put to production, no single log file to look into for root cause analysis and no single team to assign found bugs to. Instead there are deployments happening during test runs, as many log files as there are microservices and many teams to mess with the product.
At REWE digital we took a strictly team-driven QA approach. Our teams tried a lot of good and bad ideas to QA our microservice ecosystem. This involves automated testing, but also monitoring, logging and alerting practices.
In this talk I will present some of the best and worst of those ideas and explain how we try to implement a minimal QA alignment.
- – - – - – - – - – - –
Get access to the slides here: