Continuous Delivery durch Events

Über die Jahre hinweg haben wir natürlich bei einer Vielzahl an Projekten Deploymentprozesse für Infrastructure as Code entwickelt. Entweder existieren bei Aufträgen bereits vorhandene Architekturen für das automatisierte Testen und Ausrollen von Applikationen, oder wir entwickeln diese mit unseren Kund:innen nach individuellen Bedürfnissen. Meist haben diese Lösungen eine Eigenschaft gemein: Sie sind monolithisch konstruiert.

Oft ist der gesamte Prozess zum Deployment von Applikationen in einer Konfiguration definiert; vom Herunterladen des Quellcodes bis zum Update der Ressourcen. Die Bezeichnung Pipeline hat somit natürlich auch sprachlich ihre Berechtigung. Beobachtungen und Implementierungen bedingen sich dabei gegenseitig.

Es spielt auch keine Rolle, ob eine Pipeline mit AWS CodePipeline, CircleCI oder Gitlab CI betrieben wird. All diese Werkzeuge erfordern meist eine Ablaufkonfiguration und stellen letztendlich nur sicher, dass bestimmte Aktionen in einer definierten Reihenfolge ausgeführt werden. Wie würde der Prozess für Continuous Integration und Continuous Deployment aussehen, wenn er Event-basiert konfiguriert wäre?

Der gesamte Prozess für Continuous Delivery beinhaltet meist die gleichen Entitäten: Personen, Codebasis, Änderungen, Versionen, Artefakte, Releases und Deployments. All diese Entitäten können Events auslösen, einen Status besitzen und sind mit einer eindeutigen ID versehen.

Semantic Version & Changelog

Zu den allgemeinen Vorzügen von Semantic Version und Conventional Commits gibt es bereits einen eigenständigen Artikel. Die grundlegende Idee lässt sich so zusammenfassen: Die Versionierung einer Anwendung kann automatisch durch die getätigten Änderungen erfolgen. Wenn sich Teams auf ein Schema für Commit Messages einigen, lässt sich damit der gesamte Prozess zur Versionierung von Quellcode automatisieren.

Versionierung von Quellcode mit Event-basierten Aktionen

Mit Blick auf einen Event-gesteuerten Ansatz beschreibt dieses Szenario ein push oder commit Event auf der Respository Entität. Das Ereignis lässt sich durch den Commit Hash identifizieren. So lässt sich die Versionierung automatisch durch einen entsprechenden Handler abbilden. Eine mögliche Konfiguration für GitHub Actions gibt es in dem oben bereits erwähnten Artikel zu Semantic Releases mit GitHub Actions.

Continuous Integration

Sobald eine neue Version am Quellcode festgestellt wurde, muss natürlich die Funktionsfähigkeit getestet werden. Mit den üblichen Werkzeugen für Unit Tests und Integration Tests sollte spätestens dann sichergestellt werden, dass das versionierte Produkt lauffähig ist. Wenn die Integrität der Version sichergestellt ist, wird üblicherweise ein zur Version gehöriges Artefakt erstellt und zur weiteren Verwendung abgelegt.

Continuous Integration mit Event-basierten Aktionen

Die zentrale Verwaltung von Artefakten kann unterschiedlich gelöst sein; das reicht vom Einsatz der AWS Elastic Container Registry bis hin zu einfachen Zip-Archiven mit Amazon S3.

Continuous Deployment

Wenn der Prozess zur Versionierung und Integration sauber getrennt ist, kümmert sich das Continuous Deployment lediglich um das Ausrollen der erstellen Artefakte. Auch bei diesem Schritt wird wieder deutlich, dass die notwendigen Aktionen und Informationen nur einen kleinen Kontext betreffen und sich dieser Vorgang ebenfalls losgelöst betrachten lässt:

Continuous Deployment mit Event-basierten Aktionen

Für jedes neue Artefakt wird ein Deployment ausgelöst. Ob dies mit CloudFormation Templates durchgeführt, die APIs von AWS nutzen, Dateien zu S3 lädt oder mit Terraform eine Infrastruktur provisioniert, ist unerheblich. Der Prozess des Deployment basiert im Idealfall auf einem unveränderlichen und versionierten Artefakt.

Zusamenfassung

Auch wenn die einzelnen Schritte zum Ausrollen von Anwendung wie ein starrer Ablauf wirken, kann dieser problemlos Event-basiert abgebildet werden und mit kleinen Bausteinen, die nur die Informationen kennen, die sie auch benötigen, konstruiert werden.

photo of Sebastian

Sebastian is a Senior Cloud Consultant at superluminar GmbH, AWS Serverless Hero and AWS Certified Solutions Architect. He writes here in German about AWS, Serverless, Software development, Go, TypeScript and React. English Articles can be found on his Website sbstjn.com and he can be found on Twitter under @sbstjn.