In deze blog neem ik je graag mee in hoe ik een pipeline heb opgezet in Azure DevOps ten behoeve van de verschillende projecten die wij als team bedienen in mijn huidige opdracht. Handig om te lezen als je hier zelf mee bezig gaat, of gewoon leuk om te lezen als je het een interessant onderwerp vindt.
Het is een vervolg op mijn vorige blog waar ik beschreef hoe je een Gatling framework op kan zetten en hoe je daaruit een executable fat jar kon maken die op elke server met java gebruikt kan worden. Dat is ideaal voor het uitvoeren van de testen in een pipeline. Mocht je die nog niet gelezen hebben, dan adviseer ik je die eerst even door te nemen.
Heb jij ervaring met performance testen in een andere pipeline? Of binnen Azure DevOps? Ik zie graag jou bevindingen of vragen tegemoet!
Repos
Een onderdeel van Azure DevOps is Repos (repositories). Ik gebruik een repo om de bestanden van het Gatling framework in op te slaan. Hierdoor kan ik ermee werken in de Azure DevOps pipeline.
Build
Onder Pipelines in Azure DevOps heb je de keuze tussen Builds en Releases. We kijken eerst naar Builds. Want we moeten een artifact aanmaken die we in de release pipelines kunnen gaan gebruiken. In dit geval is het beoogde artifact de executable fat jar van het Gatling framework.
Maak een nieuwe build pipeline aan. Hiervoor moet je een aantal stappen doorlopen:
Ik heb de pipeline aangemaakt via de classic editor. Je kan vervolgens aangeven waar de repo zich bevindt (source; Azure Repos Git in mijn geval) en welke repo het precies is. De volgende stap is het selecteren van een template. We kiezen voor Maven.
Met de gekozen repo als input worden er 3 stappen uitgevoerd.
Een maven commando (default “package”) wordt uitgevoerd om een build te maken.
De build wordt geplaatst in de artifact staging directory.
De build wordt als artifact gepublished zodat deze gebruikt kan worden in de release pipeline.
Nu moeten we nog het e.e.a. in de build pipeline configureren:
Selecteer een agent uit de agent pool.
Controleer de Maven POM file (ik heb bijv. meerdere modules en dus ook meerdere POM’s).
Get sources
Ik heb Clean op true gezet en vervolgens bij Clean options gekozen voor All build directories (op deze manier wordt alles netjes opgeruimd voordat de inhoud van de repo op de build agent geplaatst wordt).
Maven pom.xml
Uitvinken van JUnit Test Results → Publish to Azure Pipelines. Ik heb immers geen JUnit tests t.b.v. het Gatling framework.
Copy Files to: $(build.artifactstagingdirectory)
Hier hoef je niets aan te passen.
Publish Artifact: drop
Ook hier hoef je niets aan te passen.
Ik wil liever niet de builds handmatig triggeren. Bij tabje Triggers kan je een trigger instellen.
Ik heb hier gekozen voor Enable continuous integration. Als er dan een nieuwe commit is op de Azure repo, wordt er een build uitgevoerd. Je kan evt. nog een specifieke branch of path selecteren waar dit voor geldt.
Via Save & queue kan je een eerste build uitvoeren en een artifact maken.
Release
Via de release pipeline kan je het gepublishde artifact gebruiken en een Gatling simulatie uitvoeren. Maak een nieuwe release pipeline. Je kan deze evt. opbouwen m.b.v. een template. Ik heb dit niet gedaan.
Voeg als eerste een artifact toe. Onder Source type Build vind je nu je artifact terug. Vervolgens kan je stages toevoegen.
In onze omgeving maken we gebruik van specifieke servers die we inzetten als load generators. Dit heeft enkele redenen waaronder de benodigde capaciteit van de servers en instellingen t.b.v. Splunk. Als je de Azure DevOps agent als load generator gebruikt (kan gebruiken), heb je slechts 1 stage nodig waarbij je via een PowerShell task de simulatie kan uitvoeren (Commando kan je terugvinden in mijn vorige blog).
Mogelijk dat ook voor anderen geldt dat ze de performance test op een specifieke server moeten uitvoeren. Dus ik ga hier nog wat dieper op in. De pipeline ziet er (minimaal) als volgt uit:
Ik heb dus een stage waarin het artifact op de gewenste locatie wordt geplaatst en een stage waarin op de gewenste locatie de Gatling simulatie wordt uitgevoerd.
Voor stage 1 gebruiken we task Windows machine file copy. Mijn load generators zijn namelijk windows machines. In deze task kan je het artifact selecteren, de machine naam doorgeven van de load generator, de credentials om mee te connecten en een Destination folder waar het artifact geplaatst moet worden.
Voor stage 2 gebruiken we task PowerShell on target machines. Ook hier geef je aan om welke machine het gaat, de credentials om mee te kunnen connecten. Je kan onder Advanced de Working Directory aangeven. Het is handig om hiervoor hetzelfde in te voeren als de Destination folder in stage 1. Verder moet je deze task voorzien van een PowerShell script die de Gatling simulatie uitvoert. De code is het commando voor de fat executable jar zoals in de vorige blog beschreven.
Ook voor de release pipeline kan je triggers instellen. Dit kan onder tabje Pipeline bij het artifact:
Via de bliksemschicht kan je een continuous deployment trigger of pull request trigger instellen.
Onder het artifact heb je een klokje. Hiermee kan je een schedule instellen. Deze gebruik ik voornamelijk.
En verder?
Momenteel is de pipeline geen onderdeel van de release van de betreffende applicatie waarvoor we de performance test draaien. Dat komt ook doordat er nog geen quality gate in zit. We voeren de performance test uit en de resultaten van de performance test krijgen we ook in Splunk, maar aan het einde van de performance test is er geen evaluatie/analyse van de test. En kunnen we dus o.b.v. de pipeline ook niet oordelen of de applicatie onder load performt volgens de eisen. Ik wil dit nog verder gaan onderzoeken.
Ik heb wel een idee hoe ik dit aan kan pakken. Aan de Gatling simulatie (in de scala code) kan je assertions toevoegen. Dit kan op globaal niveau (alle requests), maar ook op request/group niveau. Als je assertions toevoegt dan zal er aan het einde van de simulatie ook een JUnit file (en JSON file) geproduceerd worden. Deze zouden we in theorie dan kunnen gebruiken om de performance te beoordelen in de pipeline.
Ik hoop dat ik jullie geïnspireerd heb met deze blog. Ik hoor het graag als jullie nog vragen hebben. En als jullie tips hebben, hoor ik dat helemaal graag natuurlijk! Dat geldt ook voor het toevoegen van een quality gate in de pipeline t.b.v. de Gatling simulatie.