Continuous Load Testing

Lasttest mit GitLab, Jenkins und Gatling in DevOps integrieren

Continuous Load Testing mit GitLab, Jenkins, Gatling und Mattermost
Stephan Dannewitz - Juli 2018

Zielstellung des Continuous Integration und Deployment Prozesses

Continuous Load Testing mit GitLab, Jenkins, Gatling und Mattermost Der finale Schritt bei Continuous-Prozessen in der Softwareentwicklung ist letztendlich die Kombination aus Continuous Integration (CI) und Continuous Deployment (CD). Ist dieser Schritt erreicht, wird die Anwendung nach jedem erfolgreichen Build deployed. Im Gegensatz zum Coninuous Delivery geschieht dies beim Continuous Deployment vollautomatisch und nicht mehr auf Knopfdruck eines Entwicklers oder DevOps.
Am Beispiel unserer Homepage möchte ich diesen Prozess gerne mit Hilfe von Gitlab, Jenkins und Gatling darstellen. Wir nutzen GitLab als Repository und Auslöser für das Continuous Deployment, Jenkins für die Automatisierung des Build- und Deploy-Prozesses und Gatling als Testwerkzeug, um die Erreichbarkeit aller Seiten zu gewährleisten.
 

Konfiguration von Jenkins und GitLab

Widmen wir uns zunächst der Konfiguration von Jenkins. Ihr benötigt das Git und GitLab Plugin für Jenkins. Zudem solltet Ihr das Gatling-Plugin installieren, wenn Ihr Eure Lasttestergebnisse von Gatling direkt in Jenkins nachvollziehen wollt.
GitLab Plugin
Git Plugin
Gatling Plugin
Im Anschluss legen wir ein Projekt mit einem aussagekräftigen Titel an und konfigurieren als erstes im Bereich "Source-Code-Management" den Pull aus dem Git-Repository. Dafür benötigt Ihr die URL eures Gits sowie die notwendigen Zugangsdaten. Hierfür kann es sich lohnen, einen eigenen GitLab-Account für Jenkins zu erstellen. Ihr könnt natürlich auch Eure eigenen Benutzerdaten verwenden. Wichtig ist nur: Ihr müsst die notwendigen Zugriffsrechte am Repository besitzen.
 
Continuous Load Testing mit GitLab, Jenkins, Gatling und Mattermost
Abbildung 2: Git Konfiguration in Jenkins
 
Eine weitere Möglichkeit wäre, Euch ein GitLab-API Token zu generien und dieses statt Eurer Nutzerdaten zu verwenden. Hierbei kann auch die Gültigkeitsdauer und der Scope des Tokens eingestellt werden. Das dafür notwendige Menü findet Ihr unter "User => Settings => Access Tokens".
 
Continuous Load Testing mit GitLab, Jenkins, Gatling und Mattermost
Abbildung 3: Erstellung eines API GitLab Tokens
 
Jetzt kommt der interessante Part: Um ein Continuous Deployment umzusetzen, müssen natürlich die entsprechenden Trigger konfiguriert werden. In unserem Fall gelten als Build-Trigger Push- sowie Merge-Events. Weiterhin könnt Ihr beim Push ins Repository auch einen Kommentar hinterlegen, der automatisch Eure Job-Pipeline in Gang setzt. Wichtig ist weiterhin die Generierung eines Secret-Tokens, um GitLab zu authorisieren, Push- und Merge-Events an Jenkins zu senden.
 
Continuous Load Testing mit GitLab, Jenkins, Gatling und Mattermost
Abbildung 4: Konfiguration der Build-Trigger in Jenkins
 
Wie bereits erwähnt ist es notwendig, GitLab so zu konfigurieren, dass Jenkins über das Push- oder Merge-Event in Kenntnis gesetzt wird. Die dafür notwendigen Einstellungen findet Ihr in dem dafür vorgesehenen GitLab Repository => Settings => Integrations. Hier findet die Konfiguration der "Webhooks" statt. Die Jenkins-Job-URL, das Secret-Token (welches wir in Jenkins generiert haben) sowie die Event-Trigger werden hier konfiguriert und gespeichert. Ob das Ganze bereits erfolgreich funktioniert, könnt Ihr über den Button "Test" ausprobieren.
 
Continuous Load Testing mit GitLab, Jenkins, Gatling und Mattermost
Abbildung 5: Konfiguration der Webhooks in GitLab
 

Lasttest mit Gatling

Den Build-Prozess unserer Homepage und den Upload werde ich in diesem Blog-Beitrag nicht weiter erläutern. Der Lasttest mit Gatling ist in unserem Fall eher ein Erreichbarkeitstest aller hochgeladenen Webseiten sowie der eingebundenen Bilder. Dafür wird während des Build-Prozesses eine .csv-Datei erstellt, die alle hochgeladenen HTML-Seiten und deren URLs enthält.
Für die Ausführung des Gatling-Scripts wird dieses zusammen mit der Projekt-Vorlage aus dem GitHub im Repository hinterlegt:
Gatling Maven Plugin
Im Build-Bereich von Jenkins muss nun lediglich auf die "pom.html" gepointed und das "Goal" festgelegt werden. Damit die Lasttestergebnisse von dem Gatling-Jenkins-Plugin gefunden und archiviert werden können, solltet Ihr zunächst in den Post-Build-Aktionen das "Enable simulation tracking" aktivieren. Weiterhin muss in der "pom.html" der Pfad zum Root-Verzeichnis Eures Projektes festgelegt werden.
 
<plugin>
	<groupId>io.gatling</groupId>
    <artifactId>gatling-maven-plugin</artifactId>
    <version>${gatling-plugin.version}</version>
    	<configuration>
            <resultsFolder>../</resultsFolder>
        </configuration>
</plugin>
 
Continuous Load Testing mit GitLab, Jenkins, Gatling und Mattermost
Abbildung 6: Konfiguration des Gatling-Lasttests via Jenkins
 

Build-Tags und Notifications

Im Bereich "Post-Build-Actions" in Jenkins kann über den Git-Publisher der Build mit einem Tag versehen werden. Empfehlenswert ist hier das Datum in den Tag zu integrieren. Da Jenkins seit Version 1.597 keine integrierten Zeitstempel als Umgebungsvariable bereitstellt, benötigen wir auch hier wieder ein Plugin. Hierfür empfehlen wir:
Build Timestamp Plugin
Achtet darauf, dass das Plugin unter "Jenkins verwalten => System konfigurieren" aktiviert und korrekt konfiguriert ist.
Der letzte Schritt ist die Konfiguration der Benachrichtung - in unserem Fall via Mattermost. Darüber wird sichergestellt, dass der zuständige Mitarbeiter jederzeit über einen erfolgreichen oder fehlerhaften Build in Kenntnis gesetzt wird. QMETHODS nutzt - wie bereits erwähnt - Mattermost als Chat- und Benachrichtigungsdienst. Auch hier gibt es ein passendes Plugin für Jenkins. Dafür müsst Ihr lediglich den Endpoint (Webhook) zu Eurem Mattermost-Chatroom hinterlegen. Bei Bedarf könnt Ihr noch ein Icon hinzufügen.
Mattermost Plugin
 

Fazit & Empfehlungen

Continuous Load Testing leicht gemacht

  • Die Integration und Kombination aller verwendeten Tools gestaltete sich als überraschend einfach. Durch die hohe Marktdurchdringung stellt Jenkins für jedes Tool das passende Plugin bereit und erleichter somit die Umsetzung von solchen Projekten.  
  • Das Lasttest Werkzeug Gatling eignet sich auch für Einsteiger hervoragend, um Continuous Prozesse einzubinden. Das Script wird mit versioniert und besteht in unserem Fall aus gerade einmal 43 Zeilen. Außerdem reicht ein Text-Editor (besser eine IDE wie bspw. IntelliJ), um das Script anzupassen. Weiterhin stellt Gatling ein Plugin bereit, um den Verlauf der Ergebnisse zu tracken. Die erzeugten HTML Reports können direkt in Jenkins geöffnet werden.  
  • GitLab hat uns von Anfang an überzeugt! Daher war es keine Überraschung, dass sich die Webhooks mit Jenkins einfach umsetzen ließen.  

Vereinzelte Stolpersteine

  • Es hat eine Weile gedauert, bis mir auffiel, dass Jenkins den Zeitstempel aus der Umgebungsvariable ${BUILD_ID} entfernt hat und dafür jetzt ein Plugin benötigt wird.  
 
Continuous Integration, Delivery und Deployment
Jenkins
Gatling
Mattermost



Ihr Kommentar zum Blog-Beitrag

Nennen Sie uns bitte Ihren Namen und E-Mail-Adresse zur Verifikation. Die E-Mail Adresse wird nicht veröffentlicht!

Ich habe die Hinweise zum Datenschutz gelesen und akzeptiere diese.

Keywords

API

 

CD

 

CI

 

DevOps

 

Gatling

 

GitLab

 

Jenkins

 

Lasttest

 

Mattermost

 

Repository

 

Scrum

 

WebHook