Wenn ein funktionierendes Testsystem zum Engpass wird - und wie wir ihn beseitigt haben

Von Ramon Schwammberger und dem Platform-Engineering-Team

Moderne Plattformen entwickeln sich nicht nur weiter - sie werden immer schneller. Mit kürzeren Release-Zyklen und immer komplexerer Infrastruktur können selbst Systeme, die jahrelang zuverlässig funktioniert haben, plötzlich alles ausbremsen. Dies ist die Geschichte, wie wir unser Testsystem fit für Multi-Plattform-Umgebungen gemacht haben - nicht durch einen Neubau von Grund auf, sondern durch behutsames Entflechten und Modernisieren, während das Geschäft weiterlief.

„Never change a running system“, sagt man gern. Warum etwas anfassen, das funktioniert? Diese Haltung findet man überall in der IT. Also konzentrieren wir uns darauf, neue Fähigkeiten aufzubauen, Innovation voranzutreiben und das nächste große Ding zu liefern - während die Systeme, die uns hierhergebracht haben, im Hintergrund stillschweigend unverändert bleiben. Bis sie uns irgendwann zurückhalten - nicht, weil sie plötzlich kaputtgehen, sondern weil sich alles um sie herum schneller bewegt.

Genau das ist unserem Testsystem passiert. Es versagte nicht - im Gegenteil, es erledigte seine Aufgabe weiterhin zuverlässig. Aber unsere Plattform entwickelte sich weiter: mit schnelleren Release-Zyklen unserer Software, des zugrunde liegenden Betriebssystems, des Kernels und der Tools. Diese Entwicklung brachte eine Anforderung mit sich, die auf dem Papier simpel klingt: Wir mussten nun sicherstellen, dass alles sowohl auf der bestehenden als auch auf der neuen Betriebssystemversion funktioniert. In der Praxis hieß das, dieselben Tests in zwei unterschiedlichen Umgebungen auszuführen - und beiden Ergebnissen vertrauen zu können.

Der Preis der grünen Wiese

Wir alle wünschen uns das Greenfield-Szenario: die Chance, ein neues Testsystem von Grund auf zu bauen - mit den Anforderungen von heute, sauberen Grenzen und Plattformbewusstsein von Anfang an. In der Realität hat dieser Weg seinen Preis. Uns war klar, dass der Bau eines „perfekten“ Systems deutlich länger dauern würde als die Weiterentwicklung des bestehenden. Und während wir an diesem Neuentwurf arbeiten, müssten unsere Engineering-Kolleginnen und -Kollegen ihren Code weiterhin manuell auf beiden Betriebssystemversionen validieren - also praktisch mit doppeltem Aufwand. Für das Unternehmen hätte das höhere Infrastrukturkosten bedeutet, für die Kunden weniger verlässliche Performance und langsamere Feature-Lieferung. Ganz zu schweigen davon, dass das Testen selbst zu kompliziert und zu stark verwoben geworden wäre. Als es darauf ankam, entschieden wir uns deshalb für den Brownfield-Ansatz.

Eine dritte Dimension kommt ins Spiel

Bis zu diesem Zeitpunkt war die Infrastruktur implizit. Es gab genau eine Version von Betriebssystem und Tooling. Das Testsystem musste sich nur darum kümmern, den richtigen Software-Stack darauf zu installieren und die Tests gegen die verschiedenen Konfigurationen laufen zu lassen. In dem Moment, in dem wir eine neue Betriebssystemversion einführten, war diese Annahme hinfällig. Die Infrastruktur war nicht länger eine feste Größe - sie wurde zu etwas, das das System verstehen und berücksichtigen musste. Der Wechsel von einer Betriebssystemversion zur anderen erfordert einen Neustart des Systems. Entwickler definierten nicht mehr nur, was getestet werden soll, sondern auch, unter welchen Bedingungen: Konfiguration, Software-Stack, Betriebssystemversion. Die Infrastruktur musste damit zu einer vollwertigen Eingangsgröße des Systems werden.

Statt die bestehende Implementierung einfach zu erweitern, gingen wir einen bewussteren Schritt und gestalteten die eine Komponente neu, die für das Auslösen und Einplanen der Tests zuständig war. Sie bestand aus einer Sammlung eng gekoppelter Skripte. Das machte es sehr schwer, das System zu verstehen oder vorherzusagen, welche Ergebnisse überhaupt möglich sind. Wir beschlossen, diese Skripte durch ein einziges Stück Software zu ersetzen, das alle Entscheidungen übernimmt und sich leicht testen lässt. Die entscheidende Randbedingung: Alles drumherum musste weiterlaufen. Die Teams hatten ihre Tests bereits definiert, und sie zum Umschreiben zu zwingen, kam nicht infrage. Statt die Schnittstelle zu ändern, ließen wir sie also exakt so, wie sie war, und setzten dahinter eine neue Implementierung. So behielten wir die Kontrolle über die Veränderung: Wir konnten zuerst das Kernverhalten ersetzen, verifizieren, dass die Ausgabe gleich bleibt, und erst dann die neue Fähigkeit einführen, Tests über mehrere Plattformen hinweg auszuführen.

Stresstest für unsere Entflechtungskünste

An diesem Punkt begann das System, seine verborgene Komplexität zu offenbaren. Sobald Tests auf beiden Betriebssystemversionen liefen, funktionierten plötzlich Abläufe nicht mehr, die eigentlich völlig unabhängig hätten sein sollen. Ein Beispiel war der Release-Prozess. Selbst wenn die Tests bestanden waren, brach der automatisierte Schritt ab, der Software in einen produktionsreifen Zustand überführt. Nichts an der Änderung berührte diese Logik direkt. Und trotzdem war sie betroffen.

Das legte etwas offen, das wir vorher nicht in vollem Umfang begriffen hatten: Das System war viel enger gekoppelt, als es aussah. Build-, Test- und Release-Schritte waren auf eine Weise miteinander verflochten, die erst sichtbar wurde, als sich etwas änderte. Erinnern Sie sich an die Skriptsammlung, die wir ersetzt hatten? Die Build- und Release-Schritte hatten ganz ähnliche Skripte, und sie alle interagierten auf subtile Weise miteinander. Wir versuchten nicht, alles auf einmal zu entflechten. Das hätte zu lange gedauert und uns zurück in das Greenfield-Szenario geführt, das wir bewusst vermieden hatten. Stattdessen wählten wir den pragmatischeren Weg: Wir ersetzten die Komponente, die wir brauchten, hielten alles andere stabil und nutzten die gewonnenen Erkenntnisse als Wegweiser für künftige Verbesserungen.

Die Kopplung blieb - aber in kleineren Clustern.

Physische Hürden überwinden

Die nächste Herausforderung war weniger architektonischer als physischer Natur. Dieselben Tests in zwei Umgebungen auszuführen ist einfach - sofern sich diese Umgebungen schlicht duplizieren lassen. In der Cloud ist das vor allem eine Kostenfrage. Aber nicht alle Tests laufen in der Cloud. Manche sind auf physische Hardware angewiesen. Und Hardware ist begrenzt: durch Rack-Platz, durch Strom und durch die Tatsache, dass man sie nicht einfach nach Bedarf vervielfältigen kann. Statt Umgebungen zu duplizieren, mussten wir sie also wiederverwenden. Die Lösung, die wir umsetzten, war im Prinzip simpel: Bei Tests, die physische Maschinen erfordern, führt das System sie zunächst auf der bestehenden Plattform aus, bootet dann in die neue Betriebssystemversion, wiederholt dieselben Tests und stellt zum Schluss den Ausgangszustand wieder her. Entscheidend ist dabei nicht die Idee selbst, sondern dass der Ablauf vollständig automatisiert war. Aus Sicht der Engineers änderte sich nichts. Sie mussten weder manuell Umgebungen wechseln noch Tests wiederholen oder irgendetwas koordinieren. Das System übernahm die gesamte Sequenz für sie.

Zuverlässigkeit durch Locking

Doch die Automatisierung brachte ihre eigene Komplexität mit. Der Testprozess war kein einzelner, linearer Ablauf. Er bestand aus vielen kleineren Schritten, verteilt über verschiedene Systeme. Manche bereiteten die Infrastruktur vor, andere führten Tests aus, wieder andere erforderten Koordination über mehrere Maschinen hinweg. Und all diese Schritte fielen nun für zwei Betriebssystemversionen an.

In einem idealen System würde man das auf Designebene lösen - durch ein umstrukturiertes Ausführungsmodell und weniger Fragmentierung. Aber auch das hätte einen deutlich größeren Umbau erfordert. Also führten wir stattdessen einen Mechanismus zur Zugriffskontrolle ein: Sobald ein Test auf einem bestimmten Host startete, wurde dieser Host für die Dauer der Ausführung gesperrt, damit kein anderer Prozess dazwischenfunken konnte. Das war nicht die eleganteste Lösung. Locking erzwingt eine Reihenfolge und begrenzt die parallele Ausführung - normalerweise versucht man, so etwas zu vermeiden. In diesem Kontext war es aber der richtige Kompromiss. Er erlaubte uns, das System zuverlässig zu machen, ohne alles andere anzuhalten.

Das Perfekte ist der Feind des Guten.

Rückblickend war das Interessanteste an dieser Arbeit keine einzelne Lösung. Es war die Erkenntnis, dass Systeme selten komplex werden, weil sie jemand so entworfen hat. Sie wachsen so - langsam, schrittweise und oft aus Gründen, die zum damaligen Zeitpunkt gut waren. Genau das haben wir in unserem Testsystem gesehen.

Heute ist das System nicht perfekt. Aber es kann grundlegend mehr als zuvor. Tests laufen jetzt ohne manuelles Zutun über mehrere Plattformen hinweg. Engineers müssen ihre Arbeit nicht mehr doppelt machen, und das System bremst die Plattformentwicklung nicht mehr aus - es unterstützt sie. Wir verstehen heute viel besser, wo das System eng gekoppelt ist und warum. Wir haben gesehen, wie sich Komplexität ansammelt, wenn Verantwortlichkeiten nicht sauber getrennt sind, und wie schon kleine Änderungen versteckte Abhängigkeiten zutage fördern können. Das macht es leichter, über das System nachzudenken - nicht nur, wie es heute ist, sondern auch, wie es sich weiterentwickeln muss. Die langfristige Richtung ist klar: Das Testsystem soll sich Schritt für Schritt mehr wie eine Plattform verhalten - Engineers definieren, was sie unter welchen Bedingungen testen wollen, und das System kümmert sich um den Rest.

Der Weg dorthin braucht Zeit. Er erfordert weitere Vereinfachung und irgendwann einen gezielten Anlauf, um die verbliebene Kopplung zwischen den Komponenten abzubauen. Aber das war nie das Ziel dieser Phase. Statt alles auf einmal reparieren zu wollen, haben wir uns auf die Änderung konzentriert, auf die es am meisten ankam - Tests über mehrere Plattformen hinweg zu ermöglichen - und darum herum gebaut. Keine perfekte Lösung, aber ein bedeutsamer Schritt nach vorn.