DevOps

Bild: Pexels / Jep Gambardella - Lizenz

Wir müssen uns über DevOps unterhalten. Über jene Idee also, die seit einiger Zeit parallel, überlappend oder ergänzend zur Agilität auftritt und von dieser auch nicht klar zu trennen ist. Zum einen weil es sich um ein gutes und wichtiges Konzept handelt, das jeder der in der IT arbeitet kennen sollte, zum anderen aber auch weil es leider immer mehr verkompliziert und mystifiziert wird, bis zu dem Punkt an dem kaum noch klar ist was es sein soll. Dabei ist es eigentlich ganz einfach.

DevOps bedeutet, dass Entwicklung (Development) und Betrieb (Operations) einer Software nicht mehr von unterschiedlichen Einheiten verantwortet wird sondern von einer gemeinsamen. Das reduziert Übergaben und Wartezeiten und beschleunigt damit die Prozesse, es führt durch seinen Grundsatz "you build it, you run it" aber auch zu besserer Wartbarkeit, da kaum ein Entwickler übermässig komplex zu betreibende Software erstellen wird, wenn er weiss, dass er selbst darunter leiden würde.

Was dazukommt ist noch eine kleine aber feine Begriffs-Nuancierung. DevOps ist nicht etwa nur Dev und Ops, es bedeutet alles von Dev bis Ops. So arbeitende Teams müssen daher auch sämtliche Tätigkeiten durchführen können mit denen neu entwickelte Features in die Betriebsumgebungen kommen, also auch Integration, Test und Release sowie ggf. Rollbacks, Wiederherstellungen und Anwender-Support. Der Verantwortungsbereich wird dadurch nochmal grösser und vielfältiger.

Ein Grossteil der DevOps-Befürworter wird dieser Erklärung zwar zustimmen, gleichzeitig aber betonen, dass sie unvollständig ist. Je nach Person wird er ergänzen, dass ausserdem noch bestimmte Praktiken, Phasenmodelle,¹ Tools oder Mindsets dazugehören. Das ist zwar gut gemeint, trägt letztendlich aber nur zu der oben erwähnten Verkomplizierung und Mystifizierung bei, denn so hilfreich all das auch ist - es ist nur Mittel zum Zweck, und der Zweck bleibt das Zusammenführen von Dev, Ops und Zwischenschritten.

Werfen wir einen näheren Blick darauf. Ein DevOps-Team in dem nur die bisherigen Verantwortlichen für Entwicklung, Integration, Test, Release, Betrieb und Support zusammengefasst werden wird von Anfang an eine Unwucht haben, in der die Entwicklung neuer Funktionen nur der kleinere Teil der Aufgaben ist, die um die bestehenden Funktionen kreisenden Tätigkeiten dagegen den grösseren ausmachen. Es besteht das Risiko, dass immer mehr Kapazität dorthin verlagert wird. Aus DevOps wird nur noch Ops.

Um dem zu begegnen ist es nötig diesen grösseren Teil so zu organisieren, dass er nur einen möglichst kleinen Teil der Arbeitskapazität benötigt. Dieses Kunststück kann nur vollbracht werden indem möglichst viele Tätigkeiten aus diesem gösseren Bereich automatisiert werden und dann entweder ununterbrochen durchlaufen (z.B. Regressionstests und Monitoring) oder auf Knopfdruck durchgeführt werden können (z.B. Deployments und Rollbacks).

An dieser Stelle wird die Differenzierung offensichtlich - Praktiken, Phasenmodelle, Tools oder Mindsets können Teil von DevOps sein wenn sie dazu beitragen den Arbeitsaufwand von Nicht-Entwicklungs-Tätigkeiten zu begrenzen und zu reduzieren - was je nach Einzelfall sehr unterschiedlich aussehen kann. Dort wo sie aber zu einem grundsätzlich vorgegebenen Bestandteil erklärt werden bilden sie an vielen Stellen eine Lösung ohne Problem, die den Sinn des ganzen Ansatzes unklar werden lässt.

Das Fazit ist also: DevOps bedeutet die effektivitätssteigernde Zusammenfassung aller Tätigkeiten von Dev bis Ops, unter optionalem Einschluss weiterer Elemente, sofern die dafür sorgen, dass der Nichtentwicklungsteil so wenig aufwändig ist wie möglich. Eine schlichte Erklärung, unkompliziert, unmystisch und sofort nachvollziehbar.