Paessler AG wechselte zu GitLab und steigerte die Release-Frequenz um das Vierfache

Der PRTG Network Monitor von Paessler AG wird von Unternehmen und Organisationen aller Größen und Branchen in mehr als 170 Ländern eingesetzt. Mit einem Kundenstamm, der vom Londoner National Theatre über den Fußballclub Fulham bis hin zu Universitäten und Gesundheitseinrichtungen reicht, überwacht PRTG kontinuierlich die IT-Infrastruktur und informiert Administratoren über Probleme mit Bandbreite, Anwendungen, Netzwerken, Datenbanken und mehr – bevor Anwender überhaupt etwas bemerken.

Um einen umfassenden Monitoring-Service bereitzustellen, muss PRTG mit der Entwicklung in allen Bereichen Schritt halten. Paessler migrierte die Entwicklung von PRTG zunächst von Mercurial zu GitLab – primär für die Versionskontrolle. Eine Kombination aus einem unhandlichen 7-GB-Repository (der erste Commit erfolgte vor 20 Jahren) und problematischen Praktiken – das Fehlen von LFS in Mercurial hatte dazu geführt, dass Binärdateien direkt im Repository lagen – verursachte erhebliche Stabilitätsprobleme beim Pullen, Pushen und Mergen.

"Es gab Phasen, in denen es einfach aufgehört hat zu funktionieren – man konnte weder pullen noch pushen, und niemand wusste wirklich warum", schildert Konstantin Wolff, Infrastructure Engineer (PRTG Development).

Diese Instabilität veranlasste Paessler, nach einer Git-Lösung zu suchen. "Viele Kolleginnen und Kollegen im Unternehmen nutzten Git bereits privat und wussten, dass es schneller, besser und inzwischen der Standard ist", erklärt Greg Campion, Senior Systems Administrator. "Außerdem ist es schwieriger geworden, neue Entwickler in Mercurial einzuarbeiten, weil Git so weit verbreitet ist. Wer neu eingestellt wird, kennt Git – Mercurial kennen die wenigsten."

Nach dem Test mehrerer Versionskontrollsysteme entschieden sie sich für GitLab als Gesamtpaket. Der Wechsel zu Git brachte die benötigte Stabilität zurück und ermöglichte es Paessler, den Release-Zyklus von drei großen Releases pro Jahr auf Continuous Delivery mit monatlichen Releases zu steigern. Das vielleicht bedeutendste Ergebnis des Wechsels war jedoch ein unerwarteter Effekt auf die QA-Automatisierung.

Greg entdeckte die Möglichkeiten der GitLab-Pipelines und führte sie zunächst für sein Cloud-Team ein – von dort aus verbreiteten sie sich im gesamten Unternehmen.

"Vorher lief unser Build-Prozess über Jenkins", erklärt Konstantin. "Wir hatten einen Develop-, Release- und Master-Branch, wobei der Master-Branch schließlich veröffentlicht wurde. Jedes Mal, wenn einer dieser drei Branches gebaut wurde, wurden die Ergebnisse auf mehreren VMs installiert und anschließend startete separat die Testautomatisierung. Am Ende des Prozesses kam eine E-Mail, ob alles funktioniert hatte, was nicht geklappt hatte und wo Fehler aufgetreten waren."

Dieser sequenzielle Ablauf, bei dem Feedback erst am Ende verfügbar war, wurde nur für Develop-, Release- und Master-Branches automatisch ausgelöst. Ein QA-Engineer musste dafür etwa 10 Minuten investieren – sechs bis sieben Mal täglich. Andere Branches mussten lokal gebaut und getestet werden.

Heute sieht das grundlegend anders aus: "Jeder Branch wird getestet", sagt Greg. "Das ist fest in die Pipeline integriert. Sobald Code eingecheckt wird, läuft der gesamte Testprozess automatisch an. Dann kann direkt auf die Review-App des Branches zugegriffen werden, auf der bereits eine laufende Version von PRTG mit dem gerade eingecheckten Code bereitsteht – und die bereits getestet wurde." Das Ergebnis: höhere Qualitätskontrolle und eine deutlich engere Feedbackschleife zwischen Entwicklung und QA.

"Der Aufwand, um zur neuesten Version zu gelangen, die gerade getestet werden soll, ist für Entwickler wie für QA-Engineers enorm gesunken." Die QA-Aufgaben, die zuvor rund eine Stunde pro Tag beansprucht hatten, sind auf 30 Sekunden gesunken – eine 120-fache Beschleunigung.

Diese Automatisierung zahlt sich besonders aus, wenn etwas schiefläuft: Schlagen Tests fehl, schlägt auch die Pipeline fehl – der Entwickler weiß sofort, dass etwas nicht stimmt, ohne erst auf Rückmeldung vom QA-Team warten zu müssen. Inzwischen lösen Entwickler bei Paessler 90 Prozent ihrer QA-Aufgaben eigenständig.

Obwohl die Einführung neuer Tools in einer Organisation herausfordernd sein kann, verlief die Akzeptanz von GitLab CI/CD bei Paessler bemerkenswert reibungslos. "Es fing wirklich an sich zu verbreiten, als andere unsere Pipelines gesehen haben", erinnert sich Greg. "Wir haben eine interne Session veranstaltet nach dem Motto: 'Zeig mir deine Pipeline, ich zeig dir meine.' Alle haben ihre Pipelines präsentiert – um zu sehen, was möglich ist, was andere machen, und um neue Ideen zu sammeln. Das war eine wirklich gelungene, interessante Veranstaltung."

"GitLab wird intensiv genutzt. Und jetzt, wo so viel Interessantes damit passiert, wollen alle dabei sein."