Softwareentwicklung und Architektur/ 10.02.2022 / Thomas Strauß

Release Management: Aufbau einer automatisierten Continuous Delivery Pipeline in Kubernetes

Jeder Release ist mit einer gewissen Unsicherheit verbunden: Nimmt die gewünschte Betriebsumgebung den entwickelten Code an? Oder müssen erst langwierig Fehler behoben werden, bevor die Applikation den Nutzern zur Verfügung steht? In der Tat steckt der Release-Prozess 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. Um die Abfolge von Releases so effizient wie möglich zu gestalten, rücken Automatisierungslösungen immer stärker in den Fokus. Der folgende Artikel zeigt auf, wie ein entsprechendes Modell aussehen kann.

Release Management im Kontext von DevOps

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.

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.

Release Management verläuft in iterativen Stages

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.

Eine ausführliche Version dieses Artikels ist bei Dev-Insider erschienen.

Einblicke

Shaping the future with our clients