Wie Paessler mit GitLab Premium bis zu 50 Deployments pro Tag erreicht

Paessler wurde 1997 in Nürnberg gegründet und stellt IT-Infrastruktur-Dienste für über 200.000 Unternehmen weltweit bereit. Der PRTG Network Monitor von Paessler ist eine All-in-one-Lösung, mit der IT-Fachleute ihre Infrastruktur einfach und effektiv überwachen können. PRTG ist eine leistungsstarke Business-Lösung, die alle Systeme, Geräte, den Datenverkehr und die Anwendungen einer IT-Infrastruktur überwacht.

Paessler hatte die Entwicklung von PRTG zuvor von Mercurial zu GitLab migriert – primär für das SCM. PRTG nutzte GitLab Starter, um die Stabilität wiederherzustellen, die Release-Zeiten zu verkürzen und die Softwarequalität zu verbessern.

Nach dem schnellen Erfolg mit Starter suchten die PRTG-Entwicklungsteams nach Möglichkeiten, die zusätzlichen Funktionen von GitLab zu nutzen. Die Teams setzen Jira für Ticketing und Merging ein und wünschten sich eine vereinfachte Jira-Integration.

Das Team benötigte außerdem ein Werkzeug, um alle Pipelines im Blick zu behalten – welche Deployments laufen, welche erfolgreich waren und welche fehlgeschlagen sind. Das Operations-Dashboard von GitLab weckte ihr Interesse. Durchgängige Transparenz sollte den Teams ein besseres Verständnis von Projekten und Deployments ermöglichen und die gesamte Workflow-Performance verbessern.

Greg Campion, Cloud Engineer, und Konstantin Wolff, Architect, wandten sich mit dem Vorschlag eines Upgrades auf GitLab Premium an ihre Vorgesetzten. Da der Preisunterschied überschaubar war und Entwickler(innen) in einer deutlich schlankeren Toolchain schneller arbeiten konnten, genehmigte die IT-Leitung von PRTG den Wechsel umgehend.

Die Bereitstellung der Microservices für das Cloud-Angebot PRTG Hosted by Paessler war aufwändig, weil Terraform, Troposphere und Serverless zum Einsatz kamen und viele Integrationstests gegen AWS-Ressourcen liefen, deren Aufbau und Abbau Zeit kostete. Seit der Einführung von GitLab Premium laufen all diese Pipelines parallel, und die Laufzeit für Tests und Deployments hat sich um mehr als 66 % verringert. „Die längsten Pipelines dauerten eine Stunde. Die aufwändigste lief anderthalb Stunden. Durch den Einsatz mehrerer paralleler Runner, die Skripte ausführen und den Status anderer Jobs prüfen konnten, haben wir diese Zeit bei den schwersten Fällen auf 20 Minuten reduziert", erklärt Campion.

Premium bietet zuverlässigen Support von GitLab. PRTG musste diesen Support in zwei Jahren jedoch nur einmal in Anspruch nehmen. „Bei einem Upgrade lief etwas mit Postgres schief, und das Support-Team hatte das Problem innerhalb einer Stunde gelöst. Das war wirklich gut", sagt Campion.

Seit der Einführung von Premium gibt es bei Paessler keine Entwickler(innen) mehr, die nicht mit GitLab arbeiten. Alle Entwickler(innen), Teile des Marketing-Teams und alle, die Code schreiben, arbeiten in den über 700 Projekten innerhalb von GitLab.

Alle PRTG-Komponenten wurden zuvor in einer einzigen großen Pipeline gebaut. Diese wurde aufgeteilt, sodass jede Komponente ein eigenes Projekt mit unterschiedlichen, miteinander verknüpften Pipelines erhielt. Mit Premium gibt es nun ein zentrales Repository, das über Trigger jeder Komponente die zentrale Pipeline benachrichtigt – wodurch Pipeline-Abhängigkeiten entfallen. „Damit haben wir deutlich mehr Flexibilität als früher, als jeder Push diese große Pipeline ausgelöst hat, die dann eine halbe Stunde lief. Mit diesem Ansatz haben wir den Feedback-Zyklus für Entwickler erheblich verkürzt. Und die Pipeline-Graphen helfen uns, das Gesamtbild zu visualisieren", erklärt Wolff.

Das zentrale Repository hat dazu beigetragen, den Prozessablauf zu strukturieren und die Pipeline-Laufzeiten zu verkürzen. „Als die PRTG-Pipeline lief, inklusive Testautomatisierung bis zum Release, lagen wir zwischen 45 Minuten und fast einer Stunde – je nachdem, wie sich die Tests verhielten. Jetzt bauen wir PRTG einfach mit unserer Testautomatisierung und das dauert 15 Minuten", sagt Wolff.

Jede Gruppe innerhalb von PRTG ist nun eigenverantwortlich für den Build ihrer Projekte. Statt jedes Mal neu zu bauen, steuern Entwickler(innen) ihre eigenen Builds und fügen diese zum Gesamtpuzzle hinzu. Dieser Modularisierungsansatz ist nur durch Multi-Project-Pipelines möglich.

Mit GitLab Starter waren bis zu 15 Deployments täglich möglich – bereits eine deutliche Verbesserung gegenüber Mercurial. Seit der Einführung von Premium sind es nun 20 bis 50 Deployments pro Tag. „Wir haben 22 Microservices an einem Tag migriert. Die Migration umfasste zweimal Unit-Tests pro Repository, zweimal Integrationstests pro Repository und Deployments in drei verschiedene AWS-Umgebungen. Wenn ich also sage, wir machen ein Deployment, dann meint das jedes einzelne davon", erklärt Campion.

Entwickler(innen) haben jetzt Zugriff auf alle Funktionen, die sie für eine nahtlose Arbeit mit Jira benötigen. Teams haben Einblick in den Workflow und können den Status von Projekten innerhalb von PRTG einsehen. Und die Entwickler(innen) sind zufrieden mit dem, was läuft. „Lob bekommt man sehr selten. Aber wenn niemand klagt, ist das so gut wie Applaus", sagt Campion.