Continuous Integration mit Jenkins — wie wir aufgehört haben, freitags abends zu deployen

Noch vor einem Jahr sah unser Release-Prozess so aus: Ein Entwickler sagte „bei mir funktioniert’s“, der Betrieb erhielt eine WAR-Datei auf einem Netzlaufwerk, deployte sie am Freitag um 18:00 Uhr in die Produktion und hielt das ganze Wochenende das Telefon bereit. Heute haben wir Jenkins, automatisierte Builds und Deployment in die Testumgebung nach jedem Commit. Und am Freitagabend gehen wir ein Bier trinken. Hier ist die Geschichte.

Warum Jenkins (und nicht Bamboo, TeamCity, …)¶

Die Wahl des CI-Tools war überraschend einfach. TeamCity ist großartig, aber die Lizenz für ein größeres Team ist nicht günstig. Bamboo passt gut, wenn man im Atlassian-Ökosystem lebt (und das tun wir — JIRA, Confluence, Stash). Aber Jenkins ist kostenlos, hat ein riesiges Plugin-Ökosystem und — am wichtigsten — unser Ops-Team hatte Erfahrung damit aus früheren Projekten.

Wir haben Jenkins auf einem dedizierten RHEL-Server installiert (4 CPU, 16 GB RAM — CI braucht mehr, als man erwarten würde). Master-Slave-Architektur mit zwei Build-Agents: einer für Java-Projekte (Maven), einer für .NET-Sachen (MSBuild). Das gesamte Setup dauerte zwei Tage inklusive Integration mit Stash (Git Webhooks) und JIRA.

Pipeline: vom Commit zur Testumgebung¶

Unsere Build-Pipeline ist einfach, deckt aber das Wesentliche ab:

1. Checkout — Jenkins holt den Code aus Stash (Git) nach jedem Push
2. Build — Maven clean install, Kompilierung und Packaging
3. Unit Tests — JUnit, ~1200 Tests, laufen 4 Minuten
4. Statische Analyse — FindBugs, PMD, Checkstyle (über Sonar)
5. Deploy auf DEV — automatisches WAR-Deployment auf GlassFish
6. Integrationstests — Selenium-Tests gegen die DEV-Umgebung
7. Deploy auf TEST — manueller Trigger (ein Klick in Jenkins)

Die gesamte Pipeline vom Commit bis zu den Integrationstests dauert etwa 15 Minuten. Das ist ein enormer Fortschritt gegenüber dem Zustand „wir bauen einmal pro Woche und beten”.

SonarQube — ein Quality Gate, das schlechten Code blockiert¶

SonarQube (damals noch Sonar) war ein Game Changer für die Code-Qualität. Wir haben ein Quality Gate eingerichtet: Wenn neuer Code eine Coverage unter 70 % hat, kritische Bugs oder Sicherheitslücken enthält, schlägt der Build fehl.

Die erste Woche brachte viele rote Builds. Entwickler beschwerten sich. Aber nach einem Monat gewöhnten sie sich daran, Tests zu schreiben, und der Code verbesserte sich deutlich. Die technischen Schulden in Sonar sinken mit jedem Sprint, was einen schönen Graphen bei der Sprint-Retrospektive ergibt.

Deployment-Automatisierung — auf halbem Weg¶

Auf DEV und TEST deployen wir automatisch. Aber das Produktions-Deployment ist immer noch ein manueller Prozess mit Change Management, Genehmigung und Rollback-Plan. Und ehrlich gesagt — für unsere Kunden in regulierten Umgebungen wird das wohl auch so bleiben. Ein Auditor will nicht hören, dass ein Roboter in die Produktion deployt.

Das Deployment-Skript ist ein einfaches Bash-Skript: stoppt die GlassFish-Domain, kopiert die neue WAR, startet und prüft die Health-Check-URL. Es ist nicht Puppet oder Chef — es ist ein Skript. Aber es funktioniert und das Ops-Team versteht es. Manchmal ist Einfachheit wertvoller als Eleganz.

Git-Workflow — Feature Branches und Pull Requests¶

Zusammen mit CI sind wir auch von SVN auf Git (Atlassian Stash) umgestiegen. Und damit kamen Feature Branches und Pull Requests. Jedes Feature wird in einem eigenen Branch entwickelt, nach Fertigstellung wird ein Pull Request erstellt, ein Kollege macht ein Code Review und mergt in Develop.

Am Anfang gab es Widerstand — „warum müssen wir Code Reviews machen, das ist Zeitverschwendung.” Nach einem Monat hatten Code Reviews zwei Sicherheitsprobleme und drei Performance-Bugs aufgedeckt. Jetzt können wir uns einen Merge ohne Review nicht mehr vorstellen.

Probleme, auf die wir gestoßen sind¶

Flaky Tests. Selenium-Tests sind notorisch instabil. Ein Test besteht lokal, schlägt auf CI fehl. Lösung: explizite Waits statt Thread.sleep, isolierte Testdaten, saubere Browser-Sessions. Wir haben immer noch eine ~5 % Flaky-Rate, aber das ist besser als die 30 %, mit denen wir angefangen haben.

Build-Zeit. 15 Minuten sind OK, aber mit wachsendem Projekt wird es schlimmer. Wir erwägen die Parallelisierung von Maven-Modulen und möglicherweise den Wechsel zu Gradle, das bei inkrementellen Builds schneller ist.

Umgebungsparität. „Auf DEV funktioniert’s, auf TEST nicht” ist eine Frustration, die CI nicht vollständig löst. Aber es hilft — zumindest weiß man, dass das Build-Artefakt identisch ist. Das Problem liegt in der Umgebungskonfiguration, die wir noch manuell handhaben. Vielleicht probieren wir eines Tages Puppet oder Chef aus.

Zahlen, die für sich sprechen¶

• Release-Zyklus: von 4 Wochen auf 2 Wochen (Tendenz: 1)
• Produktionsincidents nach Release: von ~5 auf ~1 pro Quartal
• Durchschnittliche Zeit zur Fehlerbehebung: von 3 Tagen auf 4 Stunden
• Entwickler-Feedback-Loop: von „in einer Woche” auf 15 Minuten

Fangen Sie einfach an¶

Sie brauchen nicht den gesamten DevOps-Stack vom ersten Tag an. Installieren Sie Jenkins, verbinden Sie es mit Git, fügen Sie automatisierte Builds und Tests hinzu. Das allein wird die Arbeitsweise Ihres Teams verändern. Den Rest — Deployment-Automatisierung, Infrastructure as Code, Monitoring — fügen Sie schrittweise hinzu, wenn Sie bereit sind. CI ist eine Reise, kein Ziel.