Im letzten Teil der Wolkenkunde habe ich mich auf das Feld von SOA und dessen Abgrenzung zu Microservices gewagt.
In diesem Zusammenhang kommt nun in beiden Fällen etwas zum Zuge, was einer tieferen Betrachtung bedarf. Die sog. “kontinuierliche Belieferung” bzw. Continuous Delivery.
Continuous Delivery (CD) bezeichnet eine Sammlung von Techniken, Prozessen und Werkzeugen, die den Softwareauslieferungsprozess (englisch: Deployment) verbessern.
Techniken wie Continuous Integration (CI), Testautomatisierung und kontinuierliche Installation erlauben in Kombination mit agilen Methoden die Entwicklung qualitativ hochwertiger Software. Software-Build-Jobs auf CI-Servern wie Jenkins ermöglichen ein automatisiertes Testen und Erstellen von „Nightly“- oder „Release“-Versionen. Diese Versionen können mit Hilfe von CD automatisiert auf Entwicklungs-, Test-, Integrations- und Produktivumgebung eingespielt werden.
Die Automatisierung der Integrations- und Auslieferungsprozesse ermöglicht schnelle, zuverlässige und wiederholbare Deployments. Erweiterungen oder Fehlerkorrekturen können somit mit geringem Risiko und niedrigem manuellem Aufwand in die Produktivumgebung oder zum Kunden ausgeliefert werden. Continuous Delivery wird primär in Kombination mit agilen Methoden eingesetzt. Für eine Einführung von Continuous Delivery wird häufig eine Umsetzung des DevOps-Ansatzes empfohlen.
Grundprinzip
Der wichtigste Inhalt von CD ist der Weg, wie und über welchen Weg Software veröffentlicht werden soll. Dazu wird jeder Programmcode in einer Versionsverwaltung (z.B. GitHUB) hinterlegt, falls notwendig auf einem Buildserver übersetzt und dann paketiert. Weiterhin sind manuelle und automatisierte Testmethoden anzuwenden.
Entwickler, die zu einem CD-Prozess wechseln und lange Veröffentlichungszyklen gewohnt sind, müssen ihre Entwicklungstechniken anpassen. Jede Version in der Versionsverwaltung soll zu jeder Zeit lieferbar sein.
Quellenhinweise: