Continuous Delivery

aus Wikipedia, der freien Enzyklopädie
Dies ist die aktuelle Version dieser Seite, zuletzt bearbeitet am 7. Januar 2022 um 12:10 Uhr durch imported>WA1TF0R(241745).
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)

Continuous Delivery (CD, „fortlaufende Auslieferung“) bezeichnet eine Sammlung von Techniken, Prozessen und Werkzeugen, die den Software-Auslieferungsprozess (englisch deployment) verbessern.

Techniken wie Continuous Integration (CI), Testautomatisierung und kontinuierliche Installation werden insbesondere in Kombination mit agilen Methoden eingesetzt, um den Entwicklern schnelles Feedback auf Änderungen zu geben und die Software-Qualität während der Weiterentwicklung aufrechtzuerhalten. 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.

Prinzipien

Ein zentraler Begriff des CD ist die Deployment-Pipeline[1] als Lean Poka Yoke: eine Menge von Validierungen, die eine Software auf ihrem Weg zur Veröffentlichung bestehen muss. Der Programmcode wird dazu für jede Änderung, die in der Versionsverwaltung gemacht wird, falls nötig auf dem Buildserver übersetzt und dann paketiert. Es wird eine Reihe verschiedener Tests (eventuell auch manuell) ausgeführt, bevor die Software als veröffentlichungsfähig bezeichnet werden kann.

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. Entwicklungsmuster wie Featuretoggles helfen dabei, Code früh zu versionieren, auch wenn er noch nicht zur Verwendung durch den Endanwender gedacht ist. Andere Techniken wie Branching werden nicht überflüssig, müssen jedoch an den Prozess angepasst werden.

Continuous Deployment

Obwohl umgangssprachlich oftmals synonym verwendet, bezeichnet der Begriff Continuous Deployment eine weitergehende Form des Continuous Delivery, bei dem auch die Auslieferung der Software auf die Produktiv-Infrastruktur automatisch durchgeführt wird. Im Gegensatz dazu wird die Software bei Continous Delivery nur in eine Staging-Area ausgeliefert, von der sie dann manuell auf die Produktivinfrastruktur veröffentlicht werden kann.[2]

Siehe auch

  • Quality Gate – Qualitätskriterien, die eine Software erfüllen muss, um den nächsten Prozessschritt beginnen zu dürfen
  • DevOps – Eine Sammlung von Anreizen, Prozessen und Werkzeugen, die zum Ziel haben, Bruchstellen zwischen Entwicklung und IT-Betrieb zu überwinden

Literatur

  • Jez Humble, David Farley: Continuous Delivery. Reliable Software Releases Through Build, Test, and Deployment Automation (= Addison-Wesley Signature). Addison-Wesley, Upper Saddle River 2010, ISBN 978-0-321-60191-9 (englisch).
  • Eberhard Wolff: Continuous Delivery, 2. Auflage. Der pragmatische Einstieg. dpunkt, Heidelberg 2016, ISBN 978-3-86490-371-7 ([1]).
  • Michael Hüttermann: DevOps for Developers. Integrate Development and Operations, The Agile Way. Apress, New York 2012, ISBN 978-1-4302-4569-8 (englisch).

Einzelnachweise

  1. Jez Humble, Chris Read, Dan North: The Deployment Production Line. In: Joseph Chao u. a. (Hrsg.): Agile Conference, 2006. IEEE Computer Society, Washington 2006, ISBN 0-7695-2562-8, doi:10.1109/AGILE.2006.53.
  2. Carl Caum: Continuous Delivery Vs. Continuous Deployment: What's the Diff? Puppet, 30. August 2013, abgerufen am 6. Dezember 2018 (englisch).