DevOps

Der Begriff DevOps ist eine Kombination aus Development (Entwicklung) und Operations (IT Betrieb). Als Konzept betont DevOps die Kommunikation und Zusammenarbeit dieser beiden Abteilungen bei der Entwicklung von Anwendersoftware, Applikationen und Webanwendungen. Zum Einsatz kommen auch Tools, die abteilungsübergreifend nutzbar sind. Das Ziel besteht darin, den Lebenszyklus von Anwendungen so zu gestalten, dass die Anwendungsentwicklung und der IT-Betrieb enger zusammenarbeiten und dadurch Silos vermieden werden. DevOps-Strategien kommen häufig in den Bereichen Lean Management und Agile Softwareentwicklung zum Einsatz. Sie sind darüber hinaus eine Voraussetzung für den Softwarelieferprozess Continuous Delivery (CD).

Geschichte

Patrick Debois wählte den Namen DevOpsDays für eine Konferenz, die er 2009 in Gent, Belgien organisierte. In darauffolgenden Jahren wurde der Begriff DevOps stets mit agilen Methoden in Verbindung gebracht, da sich die Konferenzen mit diesen Themen befassten. Die Konferenz und insbesondere Debois Vortrag konzentrierte sich thematisch auf die Zusammenarbeit von Programmierern, IT-Spezialisten und dem operativen Produktionsmanagement sowie den Anforderungen agiler Methoden an eine Veränderung dieser Zusammenarbeit.

Das klassische Wasserfall-Modell in der Softwareentwicklung war offenbar nicht geeignet, um agilen Prozessen Rechnung zu tragen. Unterschiedliche Abteilungen waren in verschiedenem Maß agil. Das bedeutet, dass das Produktmanagement, die IT und die Entwicklung zusammen nicht funktionieren, da zum Beispiel die Entwicklung sich agil ausrichtet – aber die beiden anderen Abteilungen noch nach alten Schemata (Wasserfallmodell und DTAP) arbeiten. DevOps soll diese Brüche im Hinblick auf die Kommunikation und die Zusammenarbeit überwinden, indem das Konzept entlang des gesamten Lebenszyklus einer Anwendung integriert wird und den Einsatz von Konfigurations-, Versionsverwaltungs- und Testingtools einführt. DevOps kann dazu führen, dass

• eine Anwendung schneller auf den Markt gebracht werden kann.
• weniger Fehler und Bugs in der Anwendung vorgefunden werden.
• Updates in kürzeren Zeitabständen erfolgen können.
• im Falle eines Systemabsturzes die Zeit kürzer ist, in der das System wieder gebootet wird.

Funktionsweise

Herkömmliche Entwicklungsmodelle von Anwendungen sind in Phasen oder funktionale Einheiten unterteilt. Das DTAP-Paradigma (Development, Testing, Acceptance und Production) kennt zum Beispiel nicht nur verschiedene Teams, sondern auch entsprechende Infrastrukturen (Vgl. Staging- und Testing Environment). Eine Software würde nach diesem Paradigma erst entwickelt, getestet und qualitativ überprüft werden, bevor sie in eine Produktivumgebung migriert wird.

Bei dem Transport der Anwendungen treten häufig Konflikte auf, weil sich die Infrastrukturen unterscheiden – zum Beispiel arbeitet die Entwicklung mit Testing- und Debbugging-Tools, während die Produktionsumgebung die realen Bedingungen beim Anwender simuliert und nicht auf derartige Tools zurückgreifen kann. Sobald solche Konflikte entstehen, können auch Interessenkonflikte der beteiligten Akteure die Folge sein, da sie meist in sogenannten Silos arbeiten und kaum ein Informationsaustausch stattfindet. Falls etwas nicht wie gewünscht funktioniert, wird die Verantwortung zwischen den Abteilungen hin und her geschoben. Die anscheinend gerade bei Konzernen oft vorgefundene Praxis geht zu Lasten der Resultate. Aus den Erfahrungen mit IT-Konflikten und Interessenkonflikten entstand der DevOps-Ansatz.

DevOps setzt bei diesen Konflikten an und versucht einen Rahmen zu schaffen, der eine agile Softwareentwicklung nicht nur technisch, sondern auch menschlich ermöglicht. Andernfalls würden sich die Vorteile von agilen Methoden nicht unbedingt bemerkbar machen und die Teams wären damit befasst, die Konflikte zu nivellieren – statt die Software zu verbessern und deren Release zu ermöglichen. Die Zusammenarbeit der Entwicklung und des IT-Betriebs liegt im Fokus von DevOps, aber auch Aspekte wie Automatisierung und die Einigung auf standardisierte Prozesse während des gesamten Lebenszyklus der Software spielen eine Rolle.

Drei Grundelemente von DevOps

DevOps wird oft durch drei zentrale Elemente charakterisiert. Sie beschreiben die Stoßrichtung des Ansatzes.

• Zusammenarbeit: DevOps Befürworter setzen sich für gegenseitigen Respekt ein, der die Kommunikation zwischen Entwicklungsabteilung und IT-Betrieb leiten soll. Respekt bildet die Basis für Vertrauen und eine gute Zusammenarbeit. Auch die Selbstverpflichtung aller Akteure auf gemeinsame Ziele, aufmerksames Zuhören und Weiterbildungen zählen dazu. Eine fruchtbare Kommunikation soll als kulturelle Praxis abteilungsübergreifend etabliert werden.
• Automatisierung: Aus der Sicht der Qualitätskontrolle führen einige manuelle Aufgaben zu Problemen, da sie nur wenig transparent und nicht übertragbar auf andere Abteilungen sind. Dies wird durch die Nutzung von Tools vermieden, die für alle Akteure verfügbar sind. Der wichtigste Baustein ist die sogenannte Infrastructure as Code. Im Quellcode einer Anwendung werden während der Entwicklung bereits Daten hinterlegt, die die Installation, Konfiguration und Nutzung des Codes in der IT-Infrastruktur näher bestimmen. Konfigurationen können so zum Beispiel schnell simuliert und getestet werden. Eine zentrale Versionsverwaltung und die gemeinsame Nutzung von Vorschriften für die verschiedenen Phasen des Projektes zählen ebenfalls dazu. Tools wie Puppet oder Chef werden eingesetzt, um das Konfigurationsmanagement zu vereinheitlichen. Auch eine verteilte Software zur Versionskontrolle wie Git oder Mercurial kann verwendet werden. Das automatisierte Testen von Quellcodes wird oft durch sogenannte BDD-Tools (Behavior Driven Development; deutsch: verhaltensgetriebene Softwareentwicklung) ermöglicht, die mit dem Konfigurationsmanagement kompatibel sind. Möglich sind in diesem Zusammenhang auch Continuous Integration Server, wenn Software nach dem Continuous Delivery-Prinzip ausgeliefert werden soll. Das Ziel dieser vielen verschiedenen Tools ist es, Konflikte zwischen den Abteilungen und den verwendeten Infrastrukturen zu vermeiden.
• Prozesse: Die Einführung des DevOps-Konzeptes geht einher mit der Etablierung von verbindlichen Prozessen, die den Workflow optimieren. Diese Prozesse unterscheiden sich jedoch stark, sobald verschiedene Unternehmensgrößen ins Spiel kommen. Bei kleinen Unternehmen sind zum Beispiel die Serverumgebungen oft nicht stringent voneinander getrennt – was in großen Unternehmen anders ist. Die Frage ist, ob verbindliche Prozesse den praxisnahen Einsatz von DevOps verbessern oder komplexer werden lässt. Derzeit wird an Prozessen gearbeitet, die die Einführung von DevOps in kleinen, mittleren und großen Unternehmen ermöglichen sollen.

Bedeutung für die Programmierung

Das DevOps-Konzept möchte agile Methoden abteilungsübergreifend etablieren, um den Entwicklungs- und Release-Prozess von Anwendungen schneller, hochwertiger und konfliktarmer zu gestalten. Kritisch für die Einführung des Konzeptes ist der finanzielle Mehrwert, den die Akteure durch DevOps erzeugen können. Erst wenn die eingesetzten Methoden und Tools tatsächlich dazu führen, dass Anwendungen auch aus finanzieller Sicht gewinnbringend veröffentlicht werden können, ist DevOps eine Alternative für die Entscheider in Unternehmen. Die Verbesserung der Kommunikation und der Zusammenarbeit ist zweifelsfrei wünschenswert, doch das Fehlen von standardisierten Prozessen ist gerade in großen Unternehmen ein Problem. Zumal auch automatisierte Verfahren grundlegende Veränderungen der Infrastruktur und der täglichen Praxis notwendig machen. Letztendlich zählen die Resultate und in diesem Punkt sind agile Methoden und verwandte Konzepte in einer Situation, die den Nachweis von Fallbeispielen und Erfolgsgeschichten erforderlich machen.

Weblinks

• Definition DevOps
• Definition DevOps
• Ausführlicher Artikel über DevOps
• Wie DevOps in Unternehmen eingeführt werden kann
• Die nächst Stufe von DevOps