Standardisierte CI/CD: Gleiche Pipeline, trotzdem zu viel Handarbeit

Ihr habt eine Pipeline. Jedes Team nutzt sie. Code rein, Builds laufen, Tests werden ausgeführt, Deployments passieren. Aber irgendwie fühlt es sich immer noch an, als müsste man für jede Änderung bis zur Produktion Zähne ziehen. Die Pipeline ist da, aber der Prozess ist langsam. Jemand muss jede Änderung freigeben. QA muss die Staging-Umgebung manuell testen. Für das Deployment in die Produktion muss sich jemand hinsetzen und zu einer bestimmten Uhrzeit Befehle ausführen oder Buttons klicken.

Das ist Level 2 im CI/CD-Reifegradmodell: Standardisiert. Eure Organisation hat das Chaos überwunden, in dem jeder sein eigenes Ding gemacht hat. Es gibt eine gemeinsame Pipeline. Es gibt Konsistenz. Aber es gibt immer noch viel manuelle Arbeit, die die Auslieferung verlangsamt.

Wie Standardisierung aussieht

Auf diesem Level ist die Pipeline kein Mysterium mehr. Jedes Team folgt dem gleichen Ablauf: Commit, Build, Test, Deployment auf Staging und schließlich in die Produktion. Niemand baut mehr von seinem Laptop mit unterschiedlichen Tools oder Konfigurationen. Die Build-Umgebung ist konsistent. Die Testschritte sind definiert. Der Deployment-Prozess ist dokumentiert.

Aber hier ist der Haken: Die Pipeline stoppt beim Staging. Oder sie erfordert eine manuelle Freigabe, um fortzufahren. Oder jemand muss ein Skript ausführen. Die Automatisierung existiert, aber sie ist unvollständig. Menschen sind bei kritischen Schritten immer noch im Loop.

Das folgende Diagramm zeigt den typischen Pipeline-Ablauf auf diesem Level, wobei manuelle Schritte rot hervorgehoben sind.

Der Freigabe-Flaschenhals

Einer der größten Verlangsamer auf diesem Level ist der Freigabeprozess. Jede Änderung, die in die Produktion will, braucht das Okay einer bestimmten Person oder Gruppe. Diese Freigabe kommt vielleicht per E-Mail, Chat-Nachricht oder in einem kurzen Meeting. Aber sie kommt selten schnell.

Die Person, die freigeben muss, ist vielleicht in einem anderen Meeting. Sie ist im Urlaub. Sie ist mit einem Incident beschäftigt. Oder sie will einfach nicht die Verantwortung übernehmen, falls etwas schiefgeht. Also wartet der Change in der Pipeline. Aus Stunden werden Tage. Die Pipeline selbst ist bereit, aber der Prozess nicht.

Das ist kein Tool-Problem. Ihr könnt die beste CI/CD-Plattform der Welt haben – wenn aber jedes Deployment ein menschliches „Ja“ erfordert, seid ihr immer noch durch die Verfügbarkeit von Menschen ausgebremst.

Manuelles Testen existiert immer noch

Ein weiteres Zeichen für das standardisierte Level ist, dass nicht alle Tests automatisiert sind. Unit-Tests und Integrationstests laufen vielleicht in der Pipeline. Aber für bestimmte Szenarien muss die QA immer noch in die Staging-Umgebung einloggen, Testfälle manuell durchgehen und einen Bericht schreiben.

Das erzeugt einen Kreislauf. Ein Entwickler pusht eine Änderung. Die automatisierten Tests bestehen. Aber die QA muss die Funktion manuell verifizieren. Wenn sie ein Problem findet, geht die Änderung zurück zum Entwickler. Der Entwickler behebt es, pusht erneut, und die QA wiederholt den manuellen Test. Jede Iteration kostet Zeit.

Das Problem ist nicht, dass manuelles Testen nutzlos ist. Manche Dinge sind schwer zu automatisieren, besonders komplexe Benutzerabläufe oder Randfälle. Das Problem ist, dass manuelles Testen als ein Tor behandelt wird, das vor jedem Deployment durchschritten werden muss – selbst bei kleinen Änderungen. Das verlangsamt den gesamten Auslieferungsprozess.

Deployment bleibt ein manueller Schritt

Selbst mit einer standardisierten Pipeline bleibt das Deployment in die Produktion oft eine manuelle Aktion. Die Pipeline baut und testet vielleicht automatisch, aber wenn es darum geht, in die Produktion zu pushen, muss jemand einen Befehl ausführen oder in einem Dashboard auf einen Button klicken.

Einige Organisationen halten immer noch an einem Release-Zeitplan fest. Sie deployen einmal pro Woche oder einmal im Monat, obwohl die Pipeline bereit wäre, jederzeit zu deployen. Der Grund ist oft Angst. Ohne vollständige Automatisierung und Vertrauen in den Prozess ziehen es Teams vor, Änderungen zu bündeln und in einem geplanten Fenster zu deployen, wenn alle verfügbar sind, um Probleme zu behandeln.

Das ist verständlich, aber es untergräbt den Zweck einer Pipeline. Die Pipeline gibt euch die Fähigkeit, schnell zu deployen, aber der Prozess hindert euch daran, diese Fähigkeit zu nutzen.

Dokumentation existiert, aber ist sie nützlich?

Auf dem standardisierten Level taucht Dokumentation auf. Es gibt vielleicht eine Wiki-Seite, die erklärt, wie man deployed, wie man ein Rollback macht oder wie man mit häufigen Fehlern umgeht. Aber diese Dokumentation ist oft veraltet. Oder sie ist unvollständig. Oder Leute fragen lieber einen Kollegen, als sie zu lesen.

Das Problem ist, dass Dokumentation als separates Artefakt behandelt wird, nicht als Teil des Prozesses. Sie wird einmal geschrieben und dann vergessen. Wenn sich etwas ändert, wird die Dokumentation nicht aktualisiert. Wenn jemand Neues zum Team stößt, muss er von anderen lernen, statt aus der Doku.

Das Gute: Konsistenz

Trotz all dieser Probleme ist das standardisierte Level eine deutliche Verbesserung gegenüber dem vorherigen Level. Der größte Vorteil ist die Konsistenz. Da jedes Team die gleiche Pipeline nutzt, sind die Build- und Testergebnisse zuverlässig. Wenn ein Build fehlschlägt, schlägt er für alle auf die gleiche Weise fehl. Es gibt kein „bei mir läuft es“ mehr, weil jede Änderung denselben Weg geht.

Diese Konsistenz macht das Debuggen einfacher. Wenn etwas schiefgeht, wissen die Teams, wo sie suchen müssen. Die Pipeline-Logs sind standardisiert. Die Umgebungskonfigurationen sind gleich. Die Testschritte sind vorhersagbar. Das reduziert die Zeit für die Fehlersuche und erhöht das Vertrauen in den Prozess.

Das Schlechte: Immer noch langsam

Aber der Nachteil ist klar: zu viel manuelle Arbeit bremst alles aus. Jeder manuelle Schritt ist ein Wartepunkt. Freigabe, manuelles Testen, manuelles Deployment, veraltete Dokumentation – all das fügt Zeit zwischen dem Schreiben von Code und der Auslieferung von Wert an die Nutzer hinzu.

Teams auf diesem Level haben oft das Gefühl, Fortschritte gemacht zu haben. Sie haben eine Pipeline. Sie haben Konsistenz. Aber sie sind auch frustriert, weil die Auslieferung immer noch nicht schnell ist. Sie wissen, dass sie besser sein könnten, aber sie sind sich nicht sicher, wie sie dahin kommen.

Eine praktische Checkliste für Level 2

Wenn ihr auf diesem Level seid, hier ein paar Dinge zum Überprüfen:

• Ist jeder Freigabeschritt wirklich notwendig, oder können einige basierend auf Testergebnissen automatisiert werden?
• Welche manuellen Tests können automatisiert und in die Pipeline aufgenommen werden?
• Kann das Deployment in die Produktion automatisch ausgelöst werden, wenn alle Tests bestehen?
• Wird die Dokumentation als Teil des Deployment-Prozesses aktualisiert, nicht als separate Aufgabe?
• Warten Teams auf jemand anderen, bevor sie deployen können?

Diese Fragen helfen, die größten Flaschenhälse zu identifizieren. Das Ziel ist nicht, alle manuelle Arbeit auf einmal zu eliminieren. Es geht darum, die Schritte zu finden, die die meiste Verzögerung verursachen, und sie einen nach dem anderen zu reduzieren.

Der nächste Schritt: Self-Service

Das standardisierte Level ist eine Brücke. Eure Organisation hat das richtige Fundament. Die Pipeline existiert. Der Prozess ist konsistent. Aber ihr nutzt sie nicht voll aus. Der nächste Schritt ist, die manuelle Arbeit so weit zu reduzieren, dass Teams ihre eigenen Deployments verwalten können, ohne auf andere warten zu müssen.

Das ist das Self-Service-Level. Teams können deployen, wann sie wollen, mit automatisierten Checks, die manuelle Tore ersetzen. Freigaben werden zur Ausnahme, nicht zur Regel. Tests werden so weit wie möglich automatisiert. Dokumentation wird aus dem Prozess generiert, nicht separat geschrieben.

Aber bevor ihr dort hinkommt, müsst ihr erkennen, dass eine Pipeline zu haben nicht dasselbe ist wie schnelle Auslieferung. Standardisierung gibt euch Konsistenz. Der nächste Schritt gibt euch Geschwindigkeit.

Fazit

Eine standardisierte Pipeline ist ein guter Anfang, aber nicht die Ziellinie. Wenn euer Team eine gemeinsame Pipeline hat, aber immer noch mit langsamen Freigaben, manuellem Testen und geplanten Deployments kämpft, seid ihr auf Level 2. Die Pipeline ist bereit. Der Prozess ist es nicht. Die Aufgabe ist jetzt, die manuellen Schritte zu entfernen, die eure Auslieferung verlangsamen.