Dein Blog zum Thema digitales Business

Technische Schulden kennt jedes Team aus dem Anwendungscode. In Build, Test und Deployment entstehen sie genauso. Nur fallen sie dort seltener auf, weil niemand auf die Pipeline schaut, solange sie grün ist. Das Problem zeigt sich erst, wenn ein Build bricht, ein Deployment hängt oder ein Prüfer nach Nachweisen fragt.

Was technische Schulden in der Pipeline ausmacht

Es sind die Abkürzungen, die einmal funktioniert haben und dann geblieben sind. Ein Deploy-Skript, das nur ein Entwickler versteht. Ein Runner, der seit zwei Jahren nicht aktualisiert wurde. Gepinnte Versionen, die niemand mehr anfasst, weil ein Update angeblich alles bricht. Manuelle Schritte zwischen zwei automatischen. Jede einzelne Stelle ist für sich harmlos. In Summe wird die Pipeline langsam, brüchig und schwer zu ändern.

Warum sie unsichtbar bleiben

Anwendungscode hat Reviews, Linter und Metriken. Die Pipeline läuft im Hintergrund und wird nur bemerkt, wenn sie versagt. Solange der letzte Lauf grün war, gilt sie als in Ordnung. Dazu kommt, dass Pipeline-Wissen oft bei einer Person liegt. Wer sie gebaut hat, kennt die Stolperstellen. Alle anderen fassen sie nicht an, aus Angst, etwas kaputtzumachen. Genau das ist eine Schuld: ein Teil des Systems, den nur einer bedienen kann.

Wie man sie sichtbar macht

Der erste Schritt ist ein Inventar. Nicht das Tooling, sondern die Realität: Welche Pipelines laufen, wer sie zuletzt geändert hat, welche Schritte manuell sind, welche Abhängigkeiten und Actions veraltet sind. Danach helfen ein paar einfache Zahlen, die man ohne großen Aufwand erheben kann.

• Build-Dauer über die Zeit: Ein Build, der langsam von zwei auf zwölf Minuten wächst, ist ein Warnsignal.
• Fehlerrate und Flaky Tests: Läufe, die mal grün und mal rot sind, ohne dass sich der Code ändert.
• Alter der verwendeten Actions und Runner-Images.
• Anzahl manueller Schritte pro Deployment.
• Bus-Faktor: Wie viele Leute können die Pipeline ohne Hilfe ändern.

Diese Zahlen kosten wenig und machen aus einem diffusen Gefühl eine Liste. Erst dann lässt sich über Prioritäten reden.

Was danach kommt

Sichtbar heißt nicht behoben. Der Wert des Inventars liegt darin, dass man entscheiden kann, welche Schuld wehtut und welche man aushält. Ein veralteter Runner mit Zugriff auf Produktions-Credentials ist dringender als ein langsamer Build im Nebenprojekt. Ohne Liste wird stattdessen das behoben, was zuletzt am lautesten war. Wer die Pipeline regelmäßig inventarisiert, etwa einmal im Quartal, verhindert, dass sich Schulden still weiter aufbauen.

Der Zusammenhang mit Sicherheit

Technische Schulden in der Pipeline sind selten nur ein Tempoproblem. Ein Runner, den niemand pflegt, ist auch ein Sicherheitsrisiko. Eine Action, die seit Jahren auf einem beweglichen Tag steht, kann jederzeit fremden Code einschleusen. Ein manueller Deploy-Schritt lässt sich schlechter nachvollziehen als ein automatischer. Wer Schulden sichtbar macht, findet fast immer auch offene Sicherheitsfragen.

Ein GitSecOps QuickCheck macht genau das: Er inventarisiert die Pipeline, benennt die kritischen Stellen und zeigt, wo Tempo und Sicherheit zusammenhängen. Ergebnis in drei Werktagen, 1.990 Euro netto. Kontakt: mm@crank.zone.