In vorige blogs gaf ik aan wat agile en DevOps kunnen betekenen voor het versnellen van innovatie bij banken en hoe ING Bank en Knab dit in de praktijk doen. Daarbij werd ook duidelijk dat een belangrijke valkuil van DevOps is dat er veel aandacht is voor de cultuur, maar het inrichten van de processen wordt onderschat. Het implementeren van performance testing binnen de teams is daar een goed voorbeeld van. Dit kun je oplossen door performance testing met behulp van slimme tools te automatiseren.
Om performance testing binnen DevOps te automatiseren moet je de volgende vier aspecten goed inrichten.
1. Het genereren van load
Om een goede performance test uit te kunnen voeren heb je uiteraard load nodig. Dit kan vrijwel met elke tool afhankelijk van welke omgeving je wil testen zoals een website of een database. Er zijn verschillende tools die hierbij kunnen helpen: open source toepassing Gatling, Visual Studio van Microsoft, maar ook NeoLoad of HP’s Loadrunner werken prima op de meeste omgevingen. De tool moet het liefst geautomatiseerd aangestuurd kunnen worden vanuit de build tooling (dit zijn programma’s die de regie houden over het bouwen en testen van de software die is ontwikkeld zoals Jenkins of Octopus). Deze build tool kun je ook volgens een specifiek schema de testen laten uitvoeren.
2. Een omgeving voor het opslaan van de resultaten
Vervolgens draai je de test en heb je een locatie nodig om de resultaten van de test op te slaan zodat je deze kunt bekijken en vergelijken met vorige testen. Je wil als ontwikkelaar immers zien of de webpagina vandaag net zo snel laadt als gister. Om deze trends te kunnen zien heb je een time series database nodig zoals Graphite of InfluxDB. Deze database hoef je niet on premise te draaien, maar kan ook in een hosted omgeving worden ondergebracht.
Het hoofddoel van een automatische performance test moet zijn om zoveel mogelijk resultaten te behalen die je met elkaar kunt vergelijken. Bijvoorbeeld: hoe presteert de huidige build tegen de vorige 10 builds? Dat de situatie in de test niet 100% realistisch is, is van minder belang. Het gaat er vooral om dat je de test van vandaag kunt vergelijken met de resultaten van gisteren. Voordat het eindproduct in productie gaat voer je namelijk sowieso nog een overkoepelende test uit die wel op basis van een real-life situatie wordt opgezet.
3. Een platform voor het presenteren van de resultaten
Als je de gegevens eenmaal in een database hebt, dan wil je ze ook laten zien. Hiervoor kun je Grafana gebruiken. Je kunt met deze tool met een door jou gekozen template, visueel weergeven wat er is gebeurd. Grafana zorgt ervoor dat je heel goed ziet wat de performance is en wat bijvoorbeeld de invloed is van nieuwe code daarop. Bovendien kun je alerts instellen zodat je in het geval van performance-cijfers die buiten de marge vallen, een seintje krijgt.
4. Het minimaliseren van afhankelijkheden
Om te zorgen dat de test altijd draait is het belangrijk dat er zo min mogelijk afhankelijkheden zijn van externe factoren, zoals bijvoorbeeld beschikbaarheid van de testdata of van je omgeving. Je wil immers niet dat de test faalt door een praktische omstandigheid zoals ongeldige testaccounts of onbeschikbaarheid van de omgeving. Als er geen codewijziging is zou de test het dus altijd moeten doen. Om dat te bereiken kan je bijvoorbeeld werken met stubs om koppelingen met externe systemen overbodig te maken.
Automatische performance testing bij een bank
Hoe werkt dit nu in de praktijk bij een bank? Stel je werkt in een scrum-team dat werkt aan een stuk middleware dat verantwoordelijk is voor het beschikbaar maken van de transacties (bij- en afschrijvingen) van klanten. Dit wordt uitgevoerd door een webservice. Je kunt met Gatling bijvoorbeeld elke nacht 1000 aanroepen genereren naar de webservice. Daarvan wordt de hoogste, laagste en gemiddelde response-tijd gemeten. Deze resultaten sla je op in Graphite en worden vervolgens met Grafana gepresenteerd zodat je kunt zien hoe die metingen zich door de tijd heen hebben ontwikkeld. Dit proces geeft ook aan dat je niet alles kunt automatiseren: het analyseren en interpreteren van de testresultaten blijft natuurlijk gewoon mensenwerk.
Wil jij het proces van performance testing binnen DevOps (her)inrichten? Neem contact met mij op via mdmeijer@computest.nl en ik denk graag mee bij het automatiseren van dit proces door samen de meest geschikte tools hiervoor te selecteren.
