Continuous Load Testing

Lasttest mit GitLab, Jenkins und Gatling in DevOps integrieren

Stephan Dannewitz - Juli 2018

Zielstellung des Continuous Integration und Deployment Prozesses

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.

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".

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.

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.

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>

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