Automatisierung im Release Management Aufbau einer Continuous-Delivery-Pipeline in Kubernetes

Release-Prozesse stecken voller möglicher Fehlerquellen, die es auszuräumen gilt. Das Release Management ist deshalb heute ein wichtiger Bestandteil der Softwareentwicklung und gewinnt aktuell immer mehr an Relevanz.

Beim iterativen Vorgehen, das durch die Einführung von agilen Methoden etabliert wird, nimmt der zeitliche Abstand zwischen neuen Softwareversionen ab. Im Idealfall wächst die Häufigkeit von Releases im gleichen Maße an. Mehrere Releases innerhalb einer Woche oder sogar innerhalb eines Tages sind keine Seltenheit mehr.

E-Book zum Thema

Unser eBook „Container-Orchestrierung“ befasst sich mit den Container-Cluster-Managern Docker Swarm, Kubernetes und Mesosphere.

eBook herunterladen

Kommen Microservice-Architekturen zum Einsatz, steigt die Komplexität der Releases durch die Menge der unterschiedlichen Artefakte an. Die einzelnen Dienste werden in vielleicht sogar in verschiedenen Umgebungen ausgerollt, für die jeweils unterschiedliche Zugänge, Tools und Schnittstellen erforderlich sind.

Durch die gestiegenen Anforderungen an das Release Management beansprucht der Release-Prozess im Entwicklungszyklus immer mehr Ressourcen. Hier kommt der Faktor Automatisierung ins Spiel: Bei manuellen Releases würden die Effizienzgewinne verpuffen, welche sich in der Softwareentwicklung aus agilen Methoden und Microservices ziehen lassen. DevOps wird eingesetzt, um diese Herausforderung zu meistern.

Im Folgenden erfahren Sie mehr über die Grundlagen des (agilen) Release Managements, wie sich dieses in einer Cloud-basierten CI/CD Pipeline realisieren lässt und welche konkreten Anwendungsfälle für die Implementierung relevant sind.

Release Management im DevOps-Kontext

Der Release-Prozess lässt sich mit der folgenden kurzen Definition beschreiben, die die zwei wesentlichen Aspekte beinhaltet: Ein Software-Release-Artefakt wird innerhalb einer bestehenden Produktionsumgebung in Betrieb genommen. Wie erfolgreich die Inbetriebnahme ist, hängt dabei von beiden Seiten ab.

Das Release Management hat dabei die Aufgabe, die Schritte im Release-Prozess vorzugeben sowie Code und Dokumentation auf ihre Qualität hin abzusichern. Ein standardisierter Ansatz für das Release Management findet sich bei ITIL (IT Infrastructure Library) im Abschnitt „Service Management Practices“.

ITIL ist im Hinblick auf DevOps nicht unumstritten, obwohl – oder gerade weil – es eine lange Historie vorweisen kann. So wird argumentiert, ITIL sei veraltet und werde durch einen modernen DevOps-Ansatz obsolet gemacht. Eine solche radikal anmutende Sichtweise ist jedoch keine rein technische Entscheidung und muss auch von Unternehmensstrukturen mitgetragen und unterstützt werden.

In hybriden und hochskalierten Umgebungen stehen konventionelle Prozessstandards wie ITIL dem DevOps-Ansatz jedoch keineswegs entgegen; vielmehr stellen sie eine sinnvolle Ergänzung dar, um die Qualität der schnell aufeinander folgenden Releases hochzuhalten. Die primäre Zielsetzung bei ITIL – nämlich die Integrität der Live-Umgebung zu schützen und sicherzustellen, dass nur geprüfte Komponenten ausgerollt werden – ist auch bei DevOps beziehungsweise Continuous Delivery eine notwendige Bedingung.

Arbeitet die Softwareentwicklung mit Scrum, ist das Release Management in jedem Sprint mit einbezogen. Statt von „Release“ wird in diesem Kontext jedoch von „Inkrement“ gesprochen. Ziel ist schließlich, dass jeder Sprint am Ende ein funktionsfähiges Produkt hervorbringt. Agile Methoden berücksichtigen jedoch nicht die speziellen Anforderungen des Betriebs. Um diesen besser gerecht zu werden, schlägt das Scrum Institute einen Sprint-übergreifenden Release-Plan vor, der mit dem Backlog vergleichbar ist.

Strategien der Release-Planung in DevOps

Die DevOps-Methodik ordnet die Möglichkeiten der Release-Planung in vier Strategien ein, welche aufsteigend nach Effizienz beziehungsweise Reifegrad sortiert werden:

Release Windows (langsame Abfolge) – Bei dieser, in der Vergangenheit oft genutzten Strategie stehen den Entwicklerteams bestimmte Zeitfenster zur Verfügung, in denen ihre Artefakte in den Betrieb gehen dürfen. Ein großer Nachteil hierbei ist, dass die Releases zeitlich deutlich auseinanderliegen, was eine schnelle Reaktion auf neue Anforderungen oder auch Fehlerkorrekturen erschwert. Handelt es sich um eine Applikation, die global und durchgehend verfügbar sein soll, ist es zudem nicht einfach, Zeitpunkte mit niedriger Auslastung für die Release Windows zu finden.

Release Train – Hinter dem Release Train verbirgt sich die Metapher einer Zugstrecke, auf der zu bestimmten Zeiten verschiedene Züge abfahren und auch zu definierten Zeiten ihr Ziel erreichen. Dieses gedankliche Modell soll vor allem in Szenarien helfen, in denen verschiedene Teams und Abteilungen zusammenarbeiten. Die Release Trains koordinieren die jeweiligen Release-Prozesse und stimmen sie aufeinander ab. Ein Nachteil hierbei ist, dass ein eher starrer Zeitplan entsteht, der sich schlecht auf rasch ändernde Anforderungen anpassen lässt. Unnötiges Warten auf den nächsten Release Train führt außerdem zu einer Verschwendung an Zeit und Ressourcen.

Release Windows (schnelle Abfolge) – Die Nachteile der beiden oben dargestellten Strategien lassen sich kompensieren, indem der zeitliche Abstand zwischen den Release Windows verkürzt wird. Hierdurch steigt jedoch auch der Aufwand für die Koordination, wodurch die kürzere Time to Market wiederum mit personellen Ressourcen „erkauft“ werden muss.

Kontinuierliche Releases – Continuous Delivery ist bei DevOps der Idealzustand. Sie ist erreicht, wenn Continuous Integration (CI) und Continuous Deployment (CD) nahtlos ineinander übergehen. Jede Änderung im Quelltext wird automatisch qualitätsgesichert und bis in die Produktionsumgebung ausgeliefert, was die Time to Market enorm beschleunigt.

Wie ein vollumfassender Continuous-Delivery-Prozess in einer Cloud-Umgebung aussehen kann, zeigt die vorangestellte Grafik.

Die Artefakte, die über eine klassische CI-Pipeline gebaut werden und die ersten Stufen der Testpyramide erfolgreich passiert haben, werden automatisch versioniert und der ersten Stage zugeordnet. Wenn die CI-Pipeline nur bis zum Komponententest laufen kann, ist diese erste Stage in der Lage mehrere Komponenten in einem Integrations oder Ende-zu-Ende Test zu validieren. War der Test erfolgreich, wurde das Qualitygate der Stage passiert und die Komponenten werden der nächsten Stage zugeordnet.

Dieses Verfahren kann so oft wiederholt werden, wie es sinnvoll erscheint. Es führt letztlich im immer gleichen Verfahren von den Dev und Test Stages auf die Preprod und auf die Prod Stage. Durch das in den Artefakten integrierte Konfigurationsmanagement mit Infrastructure-As-Code und versionierten Umgebungseigenschaften, werden die Stages durch ein Release automatisch und nachweisbar korrekt konfiguriert.

Fazit: Automatisierte Releases machen DevOps praxistauglich

Das Ziel einer echten CI/CD Pipeline ist es, den Übergang von Softwareentwicklung und Betrieb vollkommen reibungslos ablaufen zu lassen. Mit der Verbindung von DevOps, Git (GitOps) und Infrastructure as Code rückt diese ambitionierte Zielsetzung der Realität ein ganzes Stück näher. Das Betriebsteam übergibt dabei die Umgebungskonfiguration in die Cloud-Umgebung, sodass der gesamte Prozess in der Cloud abläuft. Versionierung, Installation und Tests laufen automatisch ab.

Allerdings ist dies in der Praxis eher selten anzutreffen, da in der Regel noch gewisse personelle und organisatorische Hürden bestehen. Zudem kann Continuous Delivery das volle Potenzial nur mit einem hohen Automatisierungsgrad ausschöpfen. Dies gelingt zwar mit der entsprechenden technischen Expertise und praktischen Erfahrungen, aber gerade hieran fehlt es momentan noch vielen Unternehmen.

* Thomas Strauß ist seit 2018 als Software-Architekt und Teamleiter für die AUSY Technologies Germany AG tätig. Sein Interessensschwerpunkt liegt auf verteilten Systemen mit hoher Bandbreite sowie Cloud-Architekturen im Speziellen. Im Rahmen des Technologie-Managements bei AUSY Technologies befasst er sich intensiv mit technologischen Innovationen. Thomas Strauß schloss den Studiengang Informationswissenschaft an der Universität des Saarlands mit einem Magister ab.

E-Book zum Thema

Container-Orchestrierung

Container haben die DevOps-Idee revolutioniert. Dazu bedarf es eines Container-Clusters nebst zugehöriger Verwaltungsinstrumente. Wir nehmen den Platzhirsch Kubernetes und seine direkten Konkurrenten genauer unter die Lupe.

Dieses eBook beinhaltet folgende Kapitel:

• Orchester-Meister im Vergleich
• Schwarmintelligenz für Docker
• Steuermann auf dem Containerschiff
• Dicht an der Mesosphäre

eBook „Container-Orchestrierung“ herunterladen

(ID:47884802)