Das Tool ist nie das Problem
Teams kaufen Jenkins, GitLab oder Azure DevOps, richten Pipelines ein und erwarten, dass sich der Rest von selbst ergibt. Sechs Monate später ist die Pipeline ein fragiles Konstrukt aus Copy-Paste-Skripten, das niemand anfassen will. Die Builds dauern 45 Minuten, die Hälfte der Tests ist deaktiviert, und das Deployment passiert trotzdem manuell — weil „die Pipeline gerade wieder kaputt ist".
Das ist keine Ausnahme. Es ist erschreckend häufig. Und es liegt fast nie am gewählten Werkzeug.
Ursache 1: Automatisierung ohne Strategie
Der häufigste Fehler: Teams automatisieren, was sich leicht automatisieren lässt, statt das, was den grössten Hebel hat. Der Build wird automatisiert, weil das einfach ist. Aber das manuelle Deployment, das zwei Stunden dauert und bei dem regelmäßig Fehler passieren — das bleibt manuell, weil „es kompliziert ist".
Eine Automatisierungsstrategie beginnt mit der Frage: Wo verlieren wir die meiste Zeit, und wo passieren die meisten Fehler? Die Antworten zeigen, wo Automatisierung den grössten Wert schafft. Alles andere kann warten.
Ursache 2: Pipeline als Einmalprojekt
Pipelines werden aufgebaut und dann vergessen. Niemand fühlt sich zuständig. Neue Anforderungen werden schnell reingehackt, alte Workarounds bleiben für immer. Nach einem Jahr gleicht die Pipeline einem Haufen technischer Schulden, den niemand abbauen will.
Die Lösung ist nicht revolutionär: Pipelines brauchen einen Owner. Jemanden — oder besser ein Team —, der sich für die Pflege verantwortlich fühlt. Code Reviews für Pipeline-Änderungen, regelmäßiges Refactoring, Dokumentation der Entscheidungen. Kurzum: Die Pipeline verdient die gleiche Sorgfalt wie der Anwendungscode.
Ursache 3: Fehlende Testkultur
Automatisierung ohne Tests ist wie ein Sicherheitsnetz ohne Netz. Wenn die Pipeline Code deployen kann, aber nicht weiß, ob er funktioniert, hat man nichts gewonnen — man liefert nur schneller kaputte Software aus.
Die Testpyramide ist kein neues Konzept, wird aber immer noch zu selten umgesetzt:
- Unit-Tests: Schnell, günstig, zahlreich. Decken die Kernlogik ab.
- Integrationstests: Prüfen das Zusammenspiel der Komponenten. Weniger, aber aussagekräftiger.
- End-to-End-Tests: Testen den gesamten Workflow. Wenige, aber kritische.
Viele Teams überspringen die unteren Ebenen und schreiben direkt E2E-Tests. Die sind teuer, langsam und fragil. Das Ergebnis: Tests werden deaktiviert, weil sie „zu flaky" sind. Die Pipeline wird zum Durchlauferhitzer.
Ursache 4: Kein Buy-in vom Management
DevOps Automation braucht Investitionen. Zeit für den Aufbau der Pipeline, Budget für Infrastruktur, Schulungen für das Team. Wenn das Management Automatisierung als „Entwickler-Spielzeug" betrachtet, wird es nie genug Ressourcen geben.
Die Sprache des Managements sind Zahlen. Wie viele Stunden pro Woche verbringt das Team mit manuellen Deployments? Wie oft führen manuelle Fehler zu Incidents? Was kostet ein Produktionsausfall? Diese Zahlen machen den Business Case für Automatisierung — und sie sind meistens überzeugend.
Ursache 5: Zu viel auf einmal
Ein weiterer Klassiker: Das Team versucht, in einem Quartal von „kein CI/CD" auf „vollautomatisches Deployment in Produktion" zu kommen. Das Ergebnis ist Überforderung, Frustration und ein halbfertiges System, das schlimmer ist als kein System.
Der bessere Ansatz ist schrittweise:
- Automatisierter Build: Jeder Commit wird gebaut. Klingt trivial, ist aber der wichtigste Schritt.
- Automatisierte Tests: Unit-Tests laufen bei jedem Build. Failing Tests blockieren den Merge.
- Automatisiertes Deployment in Test: Die Testumgebung wird automatisch aktualisiert.
- Automatisiertes Deployment in Staging: Mit manueller Approval-Gate.
- Automatisiertes Deployment in Produktion: Wenn das Vertrauen gewachsen ist.
Jeder Schritt ist in sich wertvoll. Und jeder Schritt baut das Vertrauen auf, das für den nächsten nötig ist.
Ursache 6: Wissenslücken im Team
Pipeline-Code ist Code. Er muss geschrieben, getestet, gereviewed und gewartet werden. Aber in vielen Teams kann nur eine Person die Pipeline anfassen — der „Jenkins-Guru" oder die „GitLab-Expertin". Wenn diese Person krank wird oder das Unternehmen verlässt, hat das Team ein Problem.
Wissenstransfer und Schulung sind keine optionalen Extras. Sie sind Voraussetzung für nachhaltige Automatisierung. Die Comquent Academy bietet hier gezielte DevOps-Trainings an, die Teams in die Lage versetzen, ihre Automatisierung selbstständig weiterzüntwickeln.
Fazit
DevOps Automation scheitert nicht an Technologie. Sie scheitert an fehlender Strategie, mangelnder Pflege, unzureichenden Tests, fehlendem Management-Support und Wissenslücken. Wer diese fünf Ursachen adressiert, hat die besten Voraussetzungen, dass die Automatisierung nicht nur aufgebaut wird, sondern auch langfristig funktioniert.
