DevOps ist keine Pipeline

Der grundlegende Gedanke hinter DevOps ist das gemeinsame Verwalten aller Aspekte in der Entwicklung durch alle Mitwirkenden. Im Gegensatz dazu sind herkömmliche Entwicklung- und Betriebsabteilungen organisatorisch getrennt, folgen unterschiedlichen Zielsetzungen und es bestehen zusätzlich technische Schnittstellen. Das Einbinden der operativen Aspekte in den Entwicklungsprozess minimiert das Projektrisiko, es ermöglicht, effizient und schnell Änderungen für den Kunden freizuschalten und somit Mehrwert zu generieren. Continuous Integration und Continuous Delivery sind dabei nur Teilaspekte.

Die Entwicklung, die Dokumentation, die Quelltext-Administration, die Versionierung, die Ausführung von Tests, das richtige Verpacken bis hin zum Ausliefern auf einen in der “Definition of Done“ definierten Grad, sind alles Teile von DevOps, welches vom Team selbst und als Ganzes verwaltet wird.

Auch wenn de facto die Präferenzen und Ausprägungen innerhalb des Teams verschieden sind, soll doch jede Person die Aspekte kennen und alle Teilbereiche eigenständig ändern, ausführen und betreiben können.

Alle Artefakte, die zum Projekt gehören, also auch, wie sich das Produkt in die Pipeline integriert (z.B. Helm, Docker, Jenkins-Konfigurationen) sind dabei im selben Projekt im Version Control System (VCS, z.B. Git). Everything as Code. Everything is Code.

Das Zusammenspiel des VCS mit der Pipeline ist dabei essenziell. So können zu jedem Zeitpunkt, auch bei noch in der Fertigung stehenden Teilen, Aspekte kontrolliert und deren Konsistenz garantiert werden. Aufgaben mit unbekanntem Aufwand, also typischerweise, neue, Cloud spezifische Aspekte, sollen von Anfang der Entwicklung angegangen werden (Shift Left), später geht man Risiken ein, es wird entweder nicht mit der nötigen Sorgfalt gearbeitet (Technical Debt) oder gar durch fehlendes Know-how viel später durch Spezialisten von aussen. Dies hat kostspielige Folgen wie Verzögerung, Behinderung anderer Projekte und Produktionsstop.

Bereits beim Entscheiden über die Entwicklungszweige übt man Einfluss auf die Pipeline aus, die über alle Versionen die Einhaltung von Qualitätsvorgaben prüft (Quality Gates). Das automatische Verpacken und Parametrieren der verschiedenen Versionen bis hin zur automatischen Generierung von Releasenotes vermeiden Fehler im Prozess. Lang laufende Tests können, je nach Aufwand, nachgelagert sein oder periodisch starten und die Pipeline validieren.

Integrative und manuelle Prozesse, wie das Ausliefern in Staging oder produktions(nahe) Umgebungen oder Operationen an Live-Systemen werden, wo immer möglich, durch die Pipeline unterstützt. Hier finden sich Shift-Right Themen wie Deployment by Feature, Blue-green Deployment, Stress und Performance Tests, E2E Testing, Chaos Testing, Monitoring und Reporting wieder, aber auch Exploratory und Mob Testing. Dies liefert ein Mass für die „Gesundheit“ und Flexibilität des Systems.

Entgegen der landläufigen Meinung ist DevOps also nicht das Errichten einer Pipeline, die von dedizierten Spezialisten gehandhabt wird, sondern die Grundlage für die Zusammenarbeit in agilen, selbst organisierten, cross-functional Teams. Hierfür müssen in den Organisationen strukturelle Änderungen vorgenommen und Räume geschaffen werden.

Wenn du nicht sicher bist, wie DevOps in deinem Umfeld umgesetzt ist, dann lass uns darüber sprechen.