In mijn vorige blogs heb ik geschreven over Gatling simulaties in een executable jar en Azure DevOps pipeline met Gatling. In het laatste blog had ik al aangegeven dat ik de performancetest onderdeel wilde laten zijn van de CD pipeline door het toevoegen van quality gates. Oftewel, ik wil dat de resultaten van de performance test automatisch beoordeeld worden in de pipeline en dat deze beoordeling verantwoordelijk is voor het wel of niet continueren van de release.
Bij mijn vorige opdracht waren we nog niet op dit punt aangekomen, maar ik heb wel al het e.e.a. uitgezocht; deels bij die opdracht en deels met de kennissessies die wij met PerformanceArchitecten maandelijks houden.
Gatling assertions
In mijn vorige blog had ik al aangegeven gebruik te willen maken van de Gatling assertions functionaliteit. Je kan aan je performancetest script assertions toevoegen. Dit beperkt zich tot assertions op het gebied van aantal transacties en responstijden. Je kan assertions toevoegen op 3 niveaus:
global: assertion wordt uitgevoerd op de resultaten van alle requests samen
forAll: assertion wordt uitgevoerd op elk request
details(path): assertion wordt uitgevoerd op een specifiek request of group (een group kan je om een set met request heen zetten; in LoadRunner wordt dit een transaction genoemd)
Voorbeelden:
Als je een gatling simulatie uitvoert en je hebt assertions gedefinieerd, dan worden aan het einde van de testrun 2 files gegenereerd:
assertions.json
assertions.xml (JUnit file)
Een belangrijk verschil in deze 2 files, is dat in de JUnit file bij een geslaagde assertion niet de gemeten waarde tijdens de test getoond wordt. Dit is bij de JSON file wel het geval. Dit is bij een op zichzelf staande test niet belangrijk, maar als je verschillende release wil gaan benchmarken is het wel waardevol om ook deze waardes te bewaren.
Gatling assertions in de pipeline
Hoe werken de assertions nu in combinatie met de Azure DevOps pipeline?
Allereerst moet je natuurlijk assertions hebben toegevoegd aan je simulatie. Voorbeeld:
Vervolgens moet je in ieder geval 2 taken aanmaken in een Azure DevOps Release pipeline:
De eerste taak (PowerShell) voert de performance test uit. Niets meer en niets minder. Als niet aan alle assertions in de Gatling simulatie wordt voldaan, zal de simulatie falen en daardoor ook de PowerShell Task:
De oplettende lezer/kijker heeft kunnen zien dat het icoontje voor de taak oranje is (warning) en niet rood (error). Dat komt doordat ik bij de Control Options heb gekozen voor “Continue on error” omdat ik evengoed graag de test resultaten wil publiceren.
Daar is de 2e taak voor: Publish Test Results.
In deze taak kan je aangeven welke type files je wil publiceren en waar deze staan (Search folder). En hier kan je vervolgens ook aangeven dat de taak moet falen in het geval van “test failures”.
En dat gebeurt in dit geval dus ook:
Dus op deze manier kan je de Gatling assertions functionaliteit inzetten als quality gate. Als niet wordt voldaan aan de vereiste kwaliteit (assertions) dan faalt de release en wordt deze niet verder uitgevoerd.
En door het publiceren van de test resultaten, kan je op een makkelijke manier achterhalen aan welke assertions niet voldaan is:
En verder?
We hebben nu gezien dat we door assertions aan de Gatling simulatie toe te voegen het resultaat van de uitvoer van de performance test kunnen beïnvloeden. Hiermee maak je het dus ook mogelijk om de flow van een release pipeline te beïnvloeden. Oftewel we kunnen de Gatling assertions als quality gate inzetten.
Er zijn nog wel 2 kanttekeningen die ik wil maken:
Het beoordelen van de resultaten van een performance test doe je niet enkel o.b.v. requirements voor responstijden en aantal (geslaagde/gefaalde) transacties. Want hoe zit het bijvoorbeeld met de applicatie die getest wordt en evt. backend systemen? Er wordt nu niet gekeken naar zaken zoals CPU en memory gebruik. Dat kan ook waardevolle informatie leveren!
Naast het voldoen aan de requirements is het ook goed om te weten hoe de performance van de huidige release zich verhoudt met voorgaande release(s).
Om bovenstaande punten weg te nemen, zijn zeker oplossingen te bedenken. Deze liggen buiten de functionaliteit van Gatling (in ieder geval de gratis versie) en ook buiten de scope van dit blog.
Ik hoop dat jullie deze blog interessant vonden en dat ik jullie heb geïnspireerd of op ideeën heb gebracht. Ik hoor ook graag jullie ideeën! Er zijn altijd meerdere oplossingen.
Comments