Agile Methoden und Frameworks sind in der Softwareentwicklung (Development) längst in größerem Umfang etabliert, aber mit dem in Betrieb (Operations) bringen der Umsetzung haben sich oft Lücken gezeigt. Eine ähnliche Vorgehensweise ist empfehlenswert, wenn es um diese Einführung und Überprüfung einer neuen Funktionalität geht. Die Kombination der Entwicklung und der Betrieb der Software ist unter dem Namen DevOps bekannt. Wie der Name nahelegt, geht es um die Verbindung beziehungsweise das Zusammenwachsen von Development und IT-Operations.
Eine Definition von DevOps
Eine Standarddefinition gibt es nicht, die Grundidee stellt einen integrierenden Zusammenhang zwischen Entwicklung und dem Betrieb von Software her. Beide Bereiche wurden in der klassisch, traditionellen IT getrennt betrachtet.
Der durch eine Integration erzielbare Fortschritt besteht darin, dass man beide Bereiche zum gegenseitigen Vorteil miteinander interagieren lassen kann. Das betrifft neben der Entwicklung und dem Betrieb insbesondere auch die Qualitätskontrolle.
DevOps ist zuerst eine Denkweise, aus der heraus eine Unternehmenskultur entstehen kann. Diese ist als Voraussetzung notwendig, um darauf technische Abläufe aufsetzen zu können. Ein erstes und einfach zu erkennendes Merkmal besteht darin, dass für Entwicklung und Operations die gleichen Verfahren und Werkzeuge eingesetzt werden, ebenso wie die gleichen Menschen daran arbeiten.
Was ist der Ausgangspunkt für DevOps?
Um das zu verstehen, kannst du den Gegensatz zu diesem Ansatz betrachten. Er besteht aus einer durchgeplanten Entwicklung.
Am Anfang werden Ziele im Detail festgelegt. Diese werden in Zwischenziele aufgeteilt und auf einzelne Gruppen von Entwicklern verteilt. Sie arbeiten einen Entwicklungsschritt nach dem anderen ab und am Ende dieses Prozesses werden alle Teile zum Endprodukt zusammengesetzt. Es versteht sich fast von selbst, dass der Betrieb (also Operations) in diesem Prozess keine Rolle spielen und nur nach Abschluss der Entwicklungsarbeit das fertige Produkt und die Dokumentation erhält.
Meistens endet hier das „Projekt“, es gilt als abgeschlossen, die Entwickler sind in neuen Projekten und meisten auch nicht mehr verfügbar, das erfolgt womöglich mit dem Hinweis, jetzt sei dieses Produkt in der Verantwortung der Operations-Abteilung.
Dieses Vorgehen kann durchaus auch Vorteile haben, ist aber nicht für alle Projekte geeignet. Die Vorteile spielt es nur dort aus, wo sich Anforderungen wenig ändern, Klarheit über die Aufgaben existiert und Stabilität und Zuverlässigkeit im Vordergrund stehen (Beispiele: „System of Records“ oder „einfache“ Produkte auf dem Stacey Landscape Diagram). Wenn kaum Änderung in den Systemen herrscht, das Umfeld stabil ist und die Qualität das wesentlichste Kriterium ist, kann der Ansatz funktionieren. Updates und Anpassungen sind nur wenige erforderlich und diese erfolgen höchstens in größeren Zeitabständen.
Das Ergebnis eines solchen Projekts ist das, was geplant wurde. Das ist solange kein Problem, wie das gewünschte Endergebnis von Anfang an bekannt ist und daher auch geplant werden kann (vgl. Stacey Landscape Diagram).
Dein Problem beginnt dann, wenn diese Anforderungen sich aber doch ändern und du diese nicht mehr erfüllen kannst (z.B. „komplexer“ Bereich beim Stacey Landscape Diagram). Heute wirst du viel öfter mit sogenannten Systems of Engagement zu tun haben. Deine Kunden greifen direkt auf diese Systeme / Produkte zu und damit auf das Angebot Ihres Unternehmens (z.B. bei XaaS). Die Anforderungen an solche Systeme ändern sich viel schneller und darauf musst du reagieren können.
Ideen zur Umsetzung flexibler Softwareentwicklung
Für Systems of Engagement und Produkten, die grundsätzlich stetigen Änderungen unterliegen, verwendest du agile Softwareentwicklung. Der Name legt die Art des Vorgehens nahe, für den also Beweglichkeit und das Reagieren auf Veränderungen im Vordergrund steht. Agile Teams verfolgen mit ihrem Vorgehen mehrere Ziele.
Agilität in der Softwareentwicklung folgt folgenden vier Leitprinzipien.
Zu diesen Prinzipien gehört allerdings auch die Überzeugung, dass die als weniger wichtig bezeichneten Punkte keineswegs völlig unwichtig sind und einfach vernachlässigt werden können. Die Idee der Agilität stellt einfach eine Präferenz in den Raum und kein einfaches Patentrezept. Du wirst in deinem Unternehmen die Gewichtung dieser Punkte nach den dort herrschenden praktischen Gegebenheiten vornehmen.
Was ist also die Aufgabe für agile Teams?
Sie sollen die notwendigen Entwicklungsschritte für neue Softwareprodukte und neue Funktionen liefern. Im Gegensatz dazu ist es die Aufgabe der IT-Operations Teams, die Systeme am Laufen zu halten. Aus diesem Gegensatz ergibt sich oft ein mehr oder weniger großer Konflikt. DevOps kannst du dementsprechend als Ansatz zur Überwindung dieses Gegensatzes sehen.
Scrum als Beispiel für die agile Softwareentwicklung
Um agile Softwareentwicklung etwas detaillierter herausarbeiten zu können, betrachten wir das agile Framework Scrum. Es geht von folgenden Annahmen aus:
Wird das Framework Scrum eingesetzt, werden die Mitarbeiter in verschiedene Rollen eingeteilt:
Die Herausforderung dieses Frameworks Scrum liegt darin, einen flexiblen Ansatz mit gerade so viel Struktur zu versehen, dass diese seine Umsetzung unterstützt. Der Arbeitsablauf von Scrum Teams wird in sogenannte Sprints (Zeitabschnitte) gegliedert. Diese dauern meist eine bis vier Wochen, sie beginnen mit Planung und enden mit der Review des Erreichten. Der springende Punkt eines Sprints ist, dass während seines Ablaufs keine Änderungen der Anforderungen zulässig sind, die das Sprint ziel gefährden. Diese Abwägung soll einen Ausgleich zwischen konzentrierter und zielorientierter Arbeit und vielen Chancen zur Anpassung der Ziele herstellen.
Die Funktionsweise von DevOps
DevOps möchte die agilen Abläufe in der Softwareentwicklung auch in den Betrieb dieser Software übernehmen.
Entwicklung entsteht aus organisatorischen Abläufen und Werkzeugen, die sich auf eine Infrastruktur stützen. Die Idee der Agilität erkennt an, dass es sich dabei um einen dynamischen Prozess handelt, weil ständig neue Anforderungen aufgenommen und bewältigt werden müssen.
Die IT-Operations bestehen aus der Administration von Systemen, die notwendigerweise nahe am Nutzer und seiner Erfahrung mit diesen Systemen ist.
Für eine Verbindung dieser zwei Bereiche stellt DevOps die folgenden Prinzipien bereit:
Voraussetzungen für DevOps
Das Etablieren einer Unternehmenskultur
Diese unterscheidet sich wesentlich von einer Unternehmensstruktur, die von starren und umfangreichen Planungen ausgeht. Wenn du DevOps in deinem Unternehmen einsetzen möchtest, solltest du das Lernen durch Experimentieren fördern.
Es ist auch von großem Vorteil, wenn nicht sogar notwendig, das Über-den-Zaun Schauen zu fördern. Implizit ist im Scrum Framework diese Idee durch das Bilden von interdisziplinären Teams bereits integriert. Es kann und soll aber auch eine Rolle in der Kommunikation verschiedener Abteilungen spielen. So darf hier auch kein Silo-Denken im Wege stehen.
Überwinden von Interessenkonflikten
Das Operations-Team kann ein System dann am zuverlässigsten betreiben, wenn es sich möglichst wenig ändert und keine neuen Funktionen integriert werden müssen. Das Interesse liegt bei Operations damit auf Stabilität und Verfügbarkeit von Systemen oder Produkten. Auf der anderen Seite möchten Entwickler tendenziell neue Funktionen implementieren, denn sie werden danach beurteilt, wie gut das System oder Produkt beim Kunden ankommt. Sie haben damit eher das Interesse daran, die Verantwortung für das korrekte Funktionieren dem Operations-Team zu zuschanzen und sich rein auf die Entwicklung zu fokussieren.
Besser ist es, wenn du beiden Teams die gemeinsame Verantwortung für eine schnelle und zuverlässige Bereitstellung von Funktionen überträgst. Dazu gehört durchaus, sich auf die wichtigsten solchen Funktionen zu beschränken oder sie zumindest zu priorisieren. Auch hier zeigt sich wieder der wesentliche Punkt von DevOps in der Integration dieser zwei Zugänge.
Wesentliche Elemente von DevOps
Der Zyklus
In groben Zügen kann der DevOps-Ansatz als Zyklus beschrieben werden. Er beginnt mit der Planung, die einen agilen Ansatz verfolgen wird. Darauf folgt die Erstellung des Quellcodes, für die üblicherweise ein automatisches Versionskontroll-Werkzeug wie Git benutzt wird. Darauf wird der Code in die Auslieferung integriert und damit für den Betrieb freigegeben.
Überwachung und Feedback schließen den Zyklus, der mit der Planung der notwendigen Korrekturen und Änderungen neu beginnen kann.
Delivery Pipeline
Diese beschreibt den Ablauf der eigentlichen Entwicklungsarbeit. Die Details werden natürlich auf die genauen Anforderungen und Gegebenheiten deines Unternehmens angepasst. Zu erwarten ist aber auf jeden Fall die Verwendung einer IDE (integrierten Entwicklungsumgebung) und zur Verbindung der Arbeit mehrerer Entwickler ein Versionskontrollsystem wie das bereits erwähnte Git. In der Build-Phase werden aus dem so erstellten Quellcode die Binärdateien erzeugt und getestet.
Dieses Testen verwendet im DevOps-Ansatz automatisierte Tools. Zu diesen gehört insbesondere auch Virtualisierung, also eine Art Simulation eines Prozesses auf einem geeignet programmierten Rechner.
Eine solche Virtualisierung ist besonders nützlich für die Darstellung von Komponenten, die sonst nicht einfach verfügbar sind.
Der Test muss aber das Zusammenwirken des Endprodukts auch mit diesen Komponenten umfassen. Zu den wesentlichen Zielen von DevOps gehört, dass diese Pipeline reibungsloser und schneller funktioniert als mit einem Ansatz zu globaler Planung am Beginn eines Projekts.
Testen in Produktionsumgebung
Dieser Aspekt wird der Erfahrung nach nicht immer so einfach möglich sein. Du wirst aber eine der Produktion möglichst ähnliche Umgebung wählen wollen. Dafür sind Dienste aus der Cloud nützlich, in der die geforderte Umgebung oft viel einfacher bereitgestellt werden kann als auf eigenen Servern.
Microservices
Als weiteres technisches Element existieren Microservices, also individuell programmierte Dienste, auf die alle Programme in einem Projekt zugreifen können. Diese Microservices sind für DevOps nicht notwendig, sie lassen sich aber sinnvoll in diesen Ansatz integrieren.
Vorteile von DevOps
DevOps bietet viele Aspekte, die bei der Softwareentwicklung und bei der Projektplanung klare Vorteile bringen für alle Beteiligten. Im Folgenden werden die positiven Auswirkungen in dem Sinne näher beschrieben.
Einbindung aller Stakeholder
Alle Parteien mit Interesse am Projekt können und sollen schon von Beginn an in den Ablauf integriert werden. Neben den Entwicklern selbst und dem Operations-Team sind das auch Partner, Zulieferer, Kunden und alle Geschäftssparten in Ihrem Unternehmen, die mit diesem Projekt zu tun haben oder zu tun haben werden.
Beherrschung der Komplexität.
Heutige Unternehmensanwendungen erstrecken sich auf verschiedene Technologien und stützen sich fast notwendigerweise auf eine intensive Vernetzung von Komponenten. Das bringt eine Komplexität mit sich, die mit zentraler Planung kaum mehr unter Kontrolle gehalten werden kann. DevOps ist ein Ansatz, der diesem Umstand Rechnung trägt.
Stärkung der Innovationsfähigkeit.
Wird wenig Verwertbares schnell verworfen, werden Ressourcen für vielversprechende Ansätze frei. Diese Wirkung von schnellem Feedback und sofortiger Reaktion darauf legt also mehr Kreativität und Innovation frei.
Schnellere Wertschöpfung
Ist ein verwertbares Produkt schnell erstellt, erhältst du nicht nur schnelles Feedback. Du hast auch schneller ein Produkt, das wirtschaftlich verwertbar ist, auch wenn es sich um eine erste Version handelt (vgl. auch WSJF und Verzögerungskosten)
Vorteile für Kunden
Weil die Kunden von Anfang an mit einbezogen werden, fühlen sie sich ernst genommen und entwickeln eine stärkere Kundenbindung. Feedback an die Entwickler des von ihnen in Zukunft verwendeten Produkts macht es wahrscheinlicher, dass sie an Bord bleiben und das so entstehende Endprodukt auch erwerben und verwenden.
Eine kurze Zusammenfassung
DevOps ist ein Begriff, der eine Kultur der Zusammenarbeit zwischen Softwareentwicklern und dem Betrieb (Fachleute) oft innerhalb der Informationstechnologie beschreibt. Ziel ist es, die Zeit für die Bereitstellung von Softwareänderungen zu verkürzen, indem die Barrieren zwischen Softwareentwicklung und IT-Betrieb abgebaut werden. DevOps zielt auch darauf ab, die Qualität der Softwarebereitstellung zu verbessern und die Geschwindigkeit der Problemlösung zu erhöhen.
