DevOps ist eine Grundeinstellung – und so funktioniert sie

Inhaltsverzeichnis

DevOps beeinflusst schon seit mehr als einem Jahrzehnt die professionelle Softwareentwicklung. Innerhalb der IT stellt es bereits eine eigene Epoche dar. Von der ursprünglichen Idee hinter DevOps haben sich viele weitere abgeleitet. Das ist nachvollziehbar, führt aber häufig zu Missverständnissen, Stilblüten und Fehlern bei der Umsetzung. Worin liegt die Essenz von DevOps, welche Vorteile liefert das Konzept und welche Konsequenzen leiten sich daraus ab?

DevOps ist eine Grundeinstellung

Ende der 2000er-Jahre erkannte man in Entwicklung und Betrieb von Software, dass die strikte Trennung der Bereiche zu kritischen Problemen führt. Entwicklerinnen und Entwickler (Dev) reichten ihren Anwendungscode einfach an den Betrieb (Ops) weiter und lösten sich damit aus jeglicher Verantwortung. Traten während des Betriebs Fehler auf, galten als Schuldige stets die Developer. Übergaben fanden häufig manuell und in langwierigen Prozessen statt, der Informationsaustausch stockte oder brach komplett ab. Der Entwicklungsprozess schritt langsamer voran als notwendig. Das kostete nicht nur Geld und senkte die Qualität, sondern beschädigte auch das Vertrauen und verhinderte Innovation.

Die Erfindung von DevOps​

Patrick Debois, IT-Berater und Unternehmer, störte sich an den organisatorischen Hindernissen, die zwischen Entwicklung und Betrieb von Software bestanden. Sein Ziel war es, diese Hindernisse auszuräumen und die Zusammenarbeit zu verbessern. Die von ihm organisierte Konferenz DevOpsDays 2009 im belgischen Gent schuf dafür die Grundlage.

Seitdem hat sich die Idee von DevOps nicht nur verbreitet, sondern als Standard sowohl in der agilen, klassischen als auch hybriden Softwareentwicklung etabliert.

Auf der ersten DevOps-Konferenz folgte daher die Entscheidung, daran etwas ändern zu wollen. Eine neue Grundeinstellung musste her, die auf drei einfachen Prinzipien basiert: vereinte Verantwortung, automatisierte Arbeitsabläufe und rasche Rückmeldungen.

Erreichen lässt sich das gesteckte Ziel nur durch einen massiven, organisatorischen Eingriff. Entwicklung und Betrieb müssen zusammenwachsen – getrennte Abteilungen sind passé. Teams müssen zusammenarbeiten. Das bedeutet, bisher oftmals getrennte Unternehmensteile aufzulösen, bisher getrennte Teams zusammenzulegen, bisher separiertes Wissen zusammenzuführen und bisher mangelndes Verständnis aufzubauen. Vorwürfe wie "Aus den Augen, aus dem Sinn!" weichen der Maxime "You build it, you run it!" Dieser Leitsatz fasst die Grundeinstellung von DevOps bis heute perfekt zusammen.

DevOps ist mehr als eine Grundeinstellung

Sobald die Entscheidung getroffen ist, gemeinsam Verantwortung tragen zu wollen, ergeben sich zwangsläufig Konsequenzen. Erfolgreiche Partnerschaften basieren nicht auf Diktat, sondern auf Kompromissen.

Zuerst müssen sowohl diejenigen, die Software entwickeln, als auch diejenigen, die sie betreiben, das gemeinsame Ziel festlegen, die eigenen Absichten und Wünsche und die der anderen verstehen und zusammenbringen. Niemand darf mehr darauf bestehen, an bisherigen Gewohnheiten und Gepflogenheiten festzuhalten. Im Konsens gilt es zu klären, wie sich Prozesse und Werkzeuge harmonisieren lassen. Vereinte Verantwortung erfordert auch ein gemeinsames Verständnis und ein gemeinsames Einverständnis für ein bestimmtes Vorgehen. Rücken alle Teammitglieder auch räumlich zusammen, dann betrifft die Konsolidierung selbstverständlich auch die gesamte Hardware-Ausstattung, von der IT-Infrastruktur bis zum Arbeitsplatzrechner. Selbstredend muss auch das Unternehmen die entsprechende Zusammenarbeit ermöglichen.

Das gemeinsame Ziel jedes DevOps-Teams sollte dabei aus mindestens zwei Komponenten bestehen: qualitativ hochwertige Softwaresysteme für die Kunden schaffen und gleichzeitig eine steigende Ausliefergeschwindigkeit garantieren. Die entscheidenden Stichworte in diesem Zusammenhang sind Customer Experience und Time-to-Market. Darunter darf aber die Developer Experience nicht leiden. Development- und Operations-Mitarbeitende sollen durch DevOps nicht zu hochgetakteten Robotern mutieren. DevOps ist also eine Grundeinstellung, die aber ebenso Praktiken und Werkzeuge kombiniert – und einen Wandel der Unternehmenskultur erfordert.

SecDevOps und Co. sind Mythen

Kaum hatte sich DevOps verbreitet und halbwegs etabliert, entwickelte der Begriff eine Eigendynamik, die in Auswüchsen wie DevSecOps oder SecDevOps, aber auch DesignOps, TestOps oder gar ArchOps mündete. Das führte zu Irritation, weil es verschiedene Aspekte vermischt, die konträr oder quer zueinander liegen.

DevOps leitet sich von Development und Operations ab. Das sind zwei Disziplinen des Software-Engineering, die sich als vertikale Aspekte bezeichnen lassen und deshalb lange getrennt behandelt wurden. Es lässt sich nur betreiben, was zuvor entwickelt wurde. Der Betrieb folgt also auf die Entwicklung.

Kürzel und Zusätze wie Sec für Security, Arch (für Architecture), Test oder Design greifen weitere Aspekte auf. Diese sind aber nicht vertikal, sondern horizontal. Sie sind während der Entwicklung und während des Betriebs relevant (siehe Abbildung 2). Sie treten während des gesamten Engineering-Prozesses immer wieder auf. Design, Sicherheit, Architektur und Test sind nicht per se unwichtiger oder wichtiger als Development und Operations, sondern immer wieder von unterschiedlicher Relevanz und Umfang.

In der Praxis lässt sich DevOps nicht immer nach dem Idealbild umsetzen, weil häufig die Strukturen und Organisationen dafür fehlen. Beispiele liefern Auftragslösungen, bei denen die Entwicklung des Softwaresystems im Kundenauftrag erfolgt, der Kunde die Anwendung dann allerdings selbst betreibt. Hier lassen sich die Organisationsstrukturen nicht aufbrechen, die drei Prinzipien vereinte Verantwortung, automatisierte Arbeitsabläufe und rasche Rückmeldungen gelten aber dennoch.

Entwicklungs- und Betriebsteam fungieren in einem solchen Fall als virtuelles DevOps-Team mit vereinter Verantwortung, automatisierten Arbeitsabläufen und raschen Rückmeldungen. Prozesse und Werkzeuge bilden die Teams entsprechend ab. Das organisatorisch und räumlich – eventuell auch hinsichtlich Entwicklung und Betrieb – getrennte Team arbeitet also vollständig transparent zusammen. Hier lässt sich dann eventuell von Dev+Ops sprechen. Auch weitere Kombinationen sind möglich – und dass sie funktionieren, beweisen zahlreiche Open-Source-Projekte tagtäglich in der Praxis. In Mischformen können also Kompetenzen aus den Bereichen Entwicklung und Betrieb quer über mehrere Unternehmen verteilt sein.