Während ich im Artikel „Die DevOps-Bewegung“ die technischen Details bewusst im Vagen gelassen habe, möchte ich nun einige wichtige Techniken konkretisieren.
Die nötigen technischen Methoden zum Aufbau der CD Pipeline bauen logisch und zeitlich aufeinander auf. Sie haben ihren Ursprung in der agilen Softwareentwicklung und wurden durch die DevOps-Bewegung wesentlich weiterentwickelt.
Zu Beginn steht in Stufe Eins die Versionsverwaltung und die im Team geteilte Code Basis. Zum Beispiel nutzen wir dafür die Open-Source Tools Git, GitLab (CE) und Nexus Repository Manager. Es gilt hier die Regel, dass die Entwickler ihren neuen Code mehrmals täglich in die geteilte Basis integrieren und dabei auftretende Fehler sofort beheben.
Darauf bauen in Stufe Zwei die automatisierten Software Tests gemäß der agilen Test-Pyramide auf (siehe Abbildung 1). Üblicherweise setzen wir in der Umsetzung die agilen Methoden Test Driven Development und Pair Programming oder Code Review ein. Hier empfiehlt es sich Open-Source Testwerkzeuge zu nutzen, die es für jede Programmierumgebung gibt und durch die wir viel Zeit beim Erstellen der Tests sparen können. Die Auswahl des Werkzeugs hängt von den technischen Rahmenbedingungen des Produkts ab, das wir bauen. Für webbasierte Produkte die auf Schnittstellen basierend mit dem http-Protokoll arbeiten und über grafische Interfaces im Browser bedient werden, empfehle ich eine Testwerkzeug-Kombination aus xUnit für die Code Klassen, Rest Assured für die Code Schnittstellen (API), Cucumber allgemein für anforderungsbasierte Tests und Selenium für das Browser Interface.
Abbildung 1: Die agile Test-Pyramide
In der dritten Stufe, der Continuous Integration, werden diese Tests dann systematisch ausgeführt, sobald der Code einer neuen Funktionalität in die Basis integriert wird. Hierfür nutzen wir den Continuous Integration Server, der den Code nach erfolgreichen automatischen Tests von den Entwicklungs- in die Testumgebungen und schließlich in die Live-Umgebung bringt (siehe Abbildung 2), sowie bei nicht erfolgreichen Tests sinnvolle Meldungen zurück an die Entwicklung gibt. Unterm Strich sparen wir mit diesem System viele Ressourcen, da die Aufwände für manuelle Tests auf ein Minimum reduziert werden. Auch bei der Auswahl des Continuous Integration Server kann man guten Gewissens zu Open Source Produkten greifen. Gute Erfahrung habe ich mit Jenkins und mit GitLab CI (CE), beides Open Source, gemacht.
Abbildung 2: Continuous Integration
Für die letzte Stufe muss schließlich ein Feedbacksystem, basierend auf Metriken aus dem Betrieb des Produkts, entwickelt werden. Hier empfiehlt sich Grafana zur Visualisierung und Analyse kombiniert mit Prometheus zum aggregieren der Metriken. Alternativ bietet sich die Elastic-Stack Werkzeugkette an. Egal welche Kombination wir wählen, alle genannten Werkzeuge sind unter Open-Source Lizenz nutzbar.
Abschließend möchte ich zwei weitere technologische Voraussetzungen nicht unerwähnt lassen, ohne die wir Continuous Delivery nur eingeschränkt umsetzen können.
Die erste Voraussetzung ist Infrastructure as a Service (IaaS), das heißt, wir sollten entweder eine Private oder eine Public Cloud für unser Produkt nutzen. Der Grund ist die viel leichtere Skalierbarkeit der Infrastruktur, die mit den Ansprüchen des Produkts mitwachsen muss. Mittlerweile gibt es ein allumfassendes Angebot in diesem Bereich, der vom Marktführer Amazon (AWS) angeführt wird, gefolgt von Microsoft (Azure). Für den On-Premises-Bereich empfiehlt sich zum Beispiel Red Hat OpenShift Container Platform.
Die zweite Voraussetzung ist eine CD-taugliche Softwarearchitektur für das zu entwickelnde Produkt zu wählen. Dazu gehört das Produkt technisch in sogenannte Microservices zu gliedern, das heißt, Produktdomänen wie zum Beispiel die Webseitenoberfläche oder die Userauthentifizierung als eigenständige Miniprodukte zu verpacken. Indem man das Gesamtprodukt aus einer Kombination von Miniprodukten entwickelt die nur lose miteinander gekoppelt sind, ergeben sich wesentliche Vorteile. Zum einen löst der Ausfall eines Miniprodukts nicht mehr einen kompletten Betriebsausfall des Produkts aus. So lässt sich z.B. der Katalog eines Webshops noch browsen, aber der Bestellvorgang nicht auslösen, wenn das Miniprodukt zur Bezahlung ausfällt. Zum anderen kann ein Miniprodukt unabhängig vom Gesamtprodukt weiterentwickelt und ausgeliefert werden, ohne den Aufwand eines Deployment des Gesamtproduktes zu erfordern. Je kleiner die auszuliefernden Miniprodukte gegliedert sein können, desto einfacher und schneller lassen sich Fehler eingrenzen und beheben. So übersteigt dann der geschäftliche Vorteil der aus sehr häufigen Deployments entsteht das damit eingegangene Risiko von Betriebsstörungen. Weiterhin können dadurch Hypothesen-getriebene Produktexperimente zu äußerst geringen Kosten durchgeführt werden.
Für beide CD Voraussetzungen gibt es bewährte Open-Source Werkzeuge mit denen sich eine Microservice Architektur in Verbindung mit IaaS optimal umsetzen lässt. Die beiden Hauptwerkzeuge die sich empfehlen sind Docker und Kubernetes. Docker kapselt die Miniprodukte in leichtgewichtigen virtuellen Laufzeitumgebungen, genannt Container, samt allen ihren Abhängigkeiten ab, so dass sie auf dem Linux Hostserver keine eigene Installation brauchen und nur sehr wenig Ressourcen verbrauchen. Es ist sinnvoll, wenn Entwickler bereits von Beginn an Docker Container für ihren Code erstellen und auf der Entwicklungsumgebung testen. Die Mini-Produkte eines Gesamtproduktes können in Containern auf verschiedenen Hostservern betrieben werden und kommunizieren untereinander durch definierte Schnittstellen über ein IP basiertes Netzwerk. Um mit diesem System das Produkt robust und fehlertolerant betreiben zu können, bedarf es zusätzlich einer Orchestrierung die dafür sorgt das Container mehrfach redundant auf unterschiedlichen Hostservern an verteilten Standorten repliziert werden und das Container mit Fehlfunktionen automatisch erneuert werden. Hierfür ist das Werkzeug der Wahl Kubernetes. Abbildung 3 zeigt das Kubernetes Betriebssystem, welches aus Master und Nodes besteht, die über mehrere verbundene Hostserver verteilt installiert sind. Innerhalb der Nodes werden die Docker Container in sogenannten Pods betrieben, überwacht und repliziert. Zusätzlich bietet es sich an, die Zusammensetzung eines Kubernetes Produktiv Systems in ein Paket zu schnüren und zu versionieren, so dass wir bestimmte Zustände unseres Produkts einfrieren und bei Bedarf beliebig oft wiederherstellen können. Hierfür steht uns der Kubernetes Package Manager Helm zur Verfügung.
Produkte die eine Kubernetes-Betriebsarchitektur nutzen, eignen sich hervorragend für CD, da sie Deployments ohne Downtime ermöglichen und auch langsames phasenweises ausrollen, sowie schnelles zurückrollen neuer Versionen beherrschen, falls Fehler auftreten.
Abbildung 3: Kubernetes Betriebsarchitektur
Je nachdem welche Programmiersprachen für die Schaffung eines Softwareprodukts gewählt wurden, bieten sich bestimmte Frameworks und Werkzeuge an, die sich sowohl gut eignen für eine Microservice Architektur, als auch geeignet für den Betrieb mit Docker und Kubernetes sind. Ich kann im Java Backend Umfeld hier Spring Boot empfehlen und für Browser basierte Frontends das JavaScript Framework Angular. Außerdem empfiehlt sich für das Management der Datenströme zwischen den Backend und Frontend Services der Einsatz des Java-basierten Werkzeuges Kafka. Zur Persistierung von Daten bieten sich noSQL Datenbanken wie MongoDB an, da sie schemafrei sind und somit besser für CD geeignet.
Die gute Nachricht ist, dass jedes einzelne dieser Frameworks oder Werkzeuge wiederum unter Open-Source Lizenzen vertrieben wird.