Anders als bei Scrum oder Kanban handelt es sich bei DevOps nicht um definierte Methoden oder Prozesse, sondern genau wie bei Agilität um eine Bewegung die einen Paradigmenwechsel in der Unternehmenskultur anstrebt. Initiiert wurde diese Bewegung von dem Belgier Patrick Debois der mit Gleichgesinnten eine agile Infrastruktur anstrebte. Inspiriert von dem Vortrag „10 Deploys per Day: Dev and Ops Cooperation at Flickr“ von John Allspaw und Paul Hammond wurden 2009 die ersten DevOps Days in Gent organisiert.
Was unterscheidet nun die DevOps Bewegung von der agilen Bewegung?
Die agile Bewegung setzte sich seit der Deklaration des agilen Manifestes 2001 zum Ziel, den Fokus auf die Erzeugung eines Kundenwertes durch eine frühe, kontinuierliche Auslieferung und auf die Humanisierung von Arbeitsprozessen in der Softwareindustrie zu richten. Durch die Einführung von Scrum und Kanban im Softwareentwicklungsprozess haben viele Unternehmen seither versucht, die Vorteile der Agilität für sich zur erschließen. Allerdings scheitern bis heute sehr viele agile Transitionen daran, dass Projektmitarbeiter Entwicklung und Betrieb eines Softwareproduktes in streng und bürokratisch voneinander getrennten Silos betrachten. Dadurch wird die Zielsetzung, nämlich die Erzeugung eines Kundenwertes, untergraben und es kann keine echte Zusammenarbeit gemäß den agilen Prinzipien entstehen. Diese Silos bestehen in größeren Unternehmen häufig aus getrennten Abteilungen innerhalb einer IT-Organisation, so z.B. Softwareentwicklung, Betrieb, Qualitätssicherung und IT-Sicherheit, die im Auftrag diverser Fachabteilungen der Business-Organisation arbeiten. Konkret entsteht dadurch bei Mitarbeitern eine verzerrte Wahrnehmung von entgegengesetzten Interessen, obwohl sie am gleichen Produkt arbeiten.
Folgendes Szenario zeigt beispielhaft die Problematik:
Auf der einen Seite gibt es Entwicklungsteams, die schnell viel Funktionalität schaffen, aber sich nicht für den Betrieb und die Qualitätssicherung des Produkts verantwortlich fühlen. Stattdessen kommunzieren sie nur über Incident-Tickets und Bug-Reports mit den Kollegen aus Betrieb und QA. Auf der anderen Seite gibt es aber Betriebsingenieure, die sich möglichst wenig Änderung am Produkt wünschen, um die Stabilität nicht zu gefährden und gleichzeitig sich nicht genügend Einblick in die Entwicklung verschaffen, damit man gemeinsam sinnvolle Metriken für die Produktverbesserung entwickeln kann. Dann gibt es wiederum die Tester, die meinen aus Gründen der Objektivität nicht zu eng mit den Entwicklern zusammenarbeiten zu können, wodurch der Testbetrieb ineffektiv und langsam wird.
Aus diesen Gründen werden bürokratische Genehmigungsverfahren aufgebaut und streng formale Übergabeprozesse zwischen Entwicklung, QA, IT-Sicherheit und Betrieb eingerichtet und zwar mit dem Ziel, die jeweils eigene Position abzusichern und bei Zwischenfällen die jeweils andere Seite zur Rechenschaft ziehen zu können. Der Erfolg des Unternehmens und des anvertrauten Produktes wird dabei zur Nebensache. Dementsprechend dauert es oft Monate bis ein neuentwickeltes Produktfeature in Betrieb genommen werden kann.
Konkret bedeutet es, diese Struktur verhindert häufige und kontinuierliche Inbetriebnahme (Continuous Deployment) neu-entwickelter Funktionalitäten, da Freigaben (Releases) im Stau stecken. Es entsteht ein zu großer Release-Umfang, wodurch die Deployments wiederum hochgradig fehleranfällig werden. Auch das schnelle Messen und Auswerten der Ergebnisse aus dem Betrieb ist damit unmöglich. Das führt nicht nur zum Verlust wichtiger Erkenntnisse zur Produktverbesserung, sondern letztendlich auch dazu, dass die Produkte nicht konkurrenzfähig sind und oft wieder vom Markt verschwinden.
Die DevOps Bewegung widmet sich genau dieser Problematik, die durch die Einführung von Agilität in vielen Unternehmen nicht überwunden werden konnte. Das Ziel von DevOps ist also Unternehmen dazu zu bringen, ein Umfeld und eine Infrastruktur zu schaffen, die es Entwicklern, Testern, Betriebsingenieuren und Business-Ownern ermöglicht, als echtes Team mit dem gemeinsamen Ziel ein Produkt so zu entwickeln und zu betreiben, dass dabei häufig und kontinuierlich ein neuer Kundenwert geliefert und messbar gemacht wird. Die Techniken, Prozesse und Werkzeuge die DevOps-orientierte Unternehmen dafür einsetzen heißen zusammengefasst Continuous Delivery (CD), erstmals definiert 2010 durch Jez Humble und David Farley in ihrem gleichnamigen Buch.
Erfolgreich mit DevOps zu sein erfordert neben echter Zusammenarbeit ohne Silos, auch dass Scrum oder Kanban Teams von der ersten Zeile Code an die Optimierung für Continuous Delivery mitentwickeln und dies in ihrer Definition of Done auch festlegen.
Bei der Komposition solcher agilen Teams reicht es also nicht aus, wenn Business Owner und Projekt-verantwortliche darauf achten, für die Erstellung der gewünschten Funktionalität qualifizierte Entwickler zu finden (zum Beispiel Java, JavaScript, Backend Framework XY, Frontend Framework YZ). Um DevOps gerecht zu werden, müssen Teams auch solche Methodenkompetenzen beherrschen und stetig erweitern, die es braucht, um eine automatisierte Lieferkette inklusive Qualitätssicherung (Continuous Delivery Pipeline) in eine Entwicklungs-, dann Test- und schließlich fehlertolerante Live-Umgebung zu schaffen. Außerdem müssen sinnvolle Metriken laufend entwickelt werden, die wertvolle Erkenntnisse zurück in die Entwicklung liefern. Das bedeutet, Entwicklung und Betrieb werden teilweise von denselben Personen ausgeführt bzw. Entwickler sind Teil von Betrieb und umgekehrt. Entweder müssen dazu sogenannte Team of Team-Konstrukte zwischen Entwicklungs- und Betriebsmannschaft gebildet werden oder ein Team umfasst die nötigen Experten aus Entwicklung und Betrieb. In jedem Fall geschieht eine Bevollmächtigung der Entwickler für den Betrieb des Softwareproduktes. Das bedeutet aber nicht das Ende von spezialisierten QA-, IT-Sicherheits- und Betriebsingenieuren, vielmehr arbeiten diese nun bereits in frühen Projektphasen mit der Entwicklung im Team zusammen, um mit ihrer Kompetenz den Aufbau der Continuous Delivery Pipeline zu begleiten.
Die CD Pipeline ist also eine Instrumentenkette, die gleichzeitig zum eigentlichen Produkt entwickelt werden muss, damit Teams die Funktionalitäten dieses Produkts auch in kurzen Abständen dem Kunden ausliefern können. Dabei soll das Risiko von Betriebsstörungen durch die kleinteiligen Auslieferungen auf ein Minimum reduziert werden. Zusätzlich soll die Pipeline automatisiert Feedback liefern, so dass es den Teams erlaubt zu lernen, wie das Produkt für Kunden noch besser entwickelt werden kann.
Dementsprechend lauten die drei Kernprinzipen von DevOps nach Wichtigkeit sortiert wie folgt:
- „Establish Flow“ (Erzeuge Fluss)
- „Enable Feedback“ (Sorge für Feedback)
- „Amplify Learning“ (Fördere das Lernen)
Abbildung 1: Die drei Kernprinzipien von DevOps