Um die Entwicklungszeiten neuer Features kürzer zu halten und möglichst früh das Feedback der Kunden umsetzen zu können, verfasste im Jahr 2001 eine Gruppe US-amerikanischer Entwickler das Agile Manifest.

Viele Unternehmen haben seither versucht, ihre Entwicklung kundenorientierter auszurichten und flexibler auf Anforderungen zu reagieren. Es wurden Scrum Teams gebildet, Sprints geplant, Retrospektiven durchgeführt, …

Aber all diese Methoden helfen nur in den ersten Phasen des Softwareentwicklungsprozesses: Bei der Planung, Anforderungsanalyse und der Umsetzung – nicht aber beim Testing, Deployment und vor allem nicht im Betrieb.

Wo beginnt und wo endet DevOps

DevOps umfasst alle Schritte der Softwareentwicklung und integriert dabei bestehende und erprobte Methoden zu einem ganzheitlichen Ansatz. Ziel ist es, die Dauer der Entwicklungszyklen soweit es geht zu verringern und eine höhere Produktqualität zu liefern.

Die Grafik zeigt die typischen Phasen des Softwareentwicklungsprozesses.

Agil

Der Softwareentwicklungsprozess beginnt mit der Planung des Releases und seiner Entwicklung. Hier greift der entsprechende agile Methodenbaukasten: Die Sprints werden geplant und das Backlog verfeinert. Das ist aber auch schon der letzte agile Schritt im Softwareherstellprozess. Alle weiteren Schritte gleichen sich – egal ob wir nach Wasserfall, V-Modell oder agilen Ansätzen arbeiten.

Continuous Integration

Ein Sourcecode-Check-in der Entwickler stößt den Integrationsprozess an. Dieser Prozess startet u.a. automatisiert Softwaretests, die den Entwicklern Rückmeldung zu ihrem Code und der fehlerfreien Interaktion mit anderen Modulen geben. Da der Prozess mehrmals am Tag laufen und möglichst automatisiert stattfinden sollte, spricht man von Continuous Integration. Eine häufige Ausführung kann jedoch nur erreicht werden, wenn möglichst viele Tests automatisiert durchgeführt werden. Es ist unmöglich, nach jedem Check-in einen Tester abzustellen, der Testpläne manuell durchklickt.

Continuous Deployment

Spätestens mit der Übergabe an das Operation-Team endet die Verantwortlichkeit der Entwickler. Häufig wird die Software noch einmal auf einem separaten Testsystem installiert und geprüft. Das Deployment kann auch direkt auf einer Staging-/Produktions-Umgebung stattfinden. Wurde auch hier hoch automatisiert entwickelt und kann schnell auf ein Produktionssystem ausgerollt werden, spricht man von Continuous Deployment bzw. Continuous Delivery. Das Agile Manifest definiert das Ergebnis eines Sprints als ein “potentially shippable” Softwarepaket, besteht aber nicht darauf, dass jeder Sprint auch ausgerollt wird. Oft werden mehrere Sprints gesammelt und dem Kunden ein Release aus zwei bis vier Sprints übergeben.

Zu einem vollständigen Zyklus gehört zu guter Letzt der Betrieb. Die Anwendung und die Infrastruktur müssen überwacht werden. Die Ergebnisse sollten wieder zurück in die nächste Planung fließen.

Der Feedback-Gedanke war bereits bei den agilen Ansätzen fundamental, DevOps greift die Idee auf und führt sie weiter. Das Verstehen des Nutzerverhaltens und der Systembenutzung sind unablässig für eine kontinuierliche Verbesserung. Doch nicht nur der Betrieb sollte Feedback geben. Jeder Schritt in diesem Kreis muss permanent kritisch hinterfragt werden. So kann ein ständiger Verbesserungsprozess für das Testen, die Integration, das Deployment etc. stattfinden. Nur durch dieses Feedback findet Innovation für die Software selbst und Innovation für den gesamten Herstellungsprozess statt und die Qualität des Produktes steigt.

Wann wird DevOps durchgeführt

Der Kern der Continuous-Philosophie ist, wie der Name bereits sagt, dass sie immer Anwendung findet. Bei der Entwicklung nach DevOps wird der gesamte Zyklus also bei jeder Codeänderung durchlaufen. Jeder Check-in des Entwicklers führt zum Bau des Produktes, zur Ausführung aller Tests, zum Rollout und im Idealfall auch direkt zum produktiven Einsatz. Es sind damit mehrere Releases pro Tag möglich. Unterstützt wird das ganze durch eine Aufhebung der Trennung zwischen den Business-, Tester-, Entwickler- und Operation-Teams. Alle Beteiligten werden als ein integriertes Team für ein Produkt und dessen gesamten Lebenszyklus zusammengebracht.

Ein Deployment bei jeder Codeänderung, vielleicht sogar auf produktiven Umgebungen, klingt zunächst nach einer verrückten Idee. Aber mittlerweile gibt es viele Möglichkeiten, so etwas zu erreichen: Durch Container-Technologien sind neue Automatisierungsmöglichkeiten entstanden, durch Microservices und Cloudkonzepte kann anders skaliert und deployt werden, bspw. mit Rolling-Updates – ohne sofort alle Endnutzer zu beeinflussen.

DevOps wird in jedem Unternehmen anders gelebt, weil jedes Unternehmen auf einer anderen Ausgangsbasis aufsetzt. Die Zielsetzung von DevOps muss zu Beginn geklärt sein. Wichtig ist, individuelle Stolpersteine, die in der jeweiligen Unternehmensstruktur und -kultur liegen, zu identifizieren und aktiv anzugehen.

DevOps als Kultur der Softwareentwicklung

DevOps bedeutet also, die agilen Ideen mit schnellem Feedback und flexiblen Anpassungen auch auf die weiteren Bereiche des Application Lifecycle anzuwenden. DevOps steht für die Möglichkeit, 100 Releases am Tag zu deployen und die Möglichkeit, durch innovative Freiräume dieses Ziel zu erreichen.

Durch Vertrauen in die Fähigkeiten des Teams und dessen Freiheit, die bestmögliche Lösung zu finden, werden enorme Potentiale geweckt. Dieser Kulturwandel für die Softwareentwicklung ermöglicht eine größere Identifikation des Teams mit dem Produkt, reduziert am Ende die Time-to-Market und erhöht dabei die Softwarequalität.

Kaum ein Softwareprodukt kann sich Innovationslosigkeit, lange Release Zyklen oder schlechte Qualität leisten und schon gar nicht im Cloud-Kontext.

Der Siegeszug von DevOps hat begonnen.