Continuous Deployment (CD) in der Softwareentwicklung
Durch Implementierung einer Continuous Deployment Pipeline werden Softwareprodukte automatisch nach jeder Änderung in einer neuen Version veröffentlicht, dies kann mehrmals täglich der Fall sein.
Im Rahmen der fortschreitenden Digitalisierung wird es immer wichtiger Innovationszyklen zu verkürzen und damit neue Versionen von Produkten in kürzeren Abständen an den Markt zu bringen. Ein großer Vorteil dabei ist es, dass durch die kontinuierlichen Releases schneller Kundenfeedback eingeholt und so kundennah entwickelt werden kann.
Vorausgesetzt ist, dass die Entwicklung des Produkts bzw. des Services einen hohen Grad an automatischen Tests beinhaltet, und die Entwicklungspipeline sehr robust ist, da es nicht möglich ist alle Änderungen durch manuelle Tests zu überprüfen.
In der Praxis wird diese Form am wenigsten verwendet.
Abgrenzung zu Continuous Delivery und Continuous Integration
Continuous Deployment, Delivery und Integration sind drei unterschiedliche „Ausbaustufen“ ein und derselben Idee: Der kontinuierlichen Weiterentwicklung von Software.
Continuous Deployment stellt dabei die höchste Ausbaustufe dar, denn hier werden alle Änderungen automatisch bis zum Kunden hin ausgeliefert. Es gibt also keine klassischen Releases.
Bei Continuous Delivery werden Änderungen zwar automatisch auf einem (internen) Server deployed, aber noch nicht an den Kunden ausgeliefert. Die Änderungen können auf diesem Server noch manuell getestet werden um dann in Form eines Releases an den Kunden übergeben zu werden.
Akademisch betrachtet liegt der Unterschied im Grad der Automatisierung bezogen auf die Methode des Deployment (Continuous Deployment: automatisch, Continuous Delivery: manuell). In der Praxis kann es jedoch vorkommen, dass diese Begriffe nahezu synonym verwendet werden.
Der Begriff Continuous Deployment kam das erste Mal 2009 in einem Blogbeitrag von Timothy Fitz auf. Rund ein Jahr später entstand das erste Werk zu Continuous Delivery - das Buch „Continuous Delivery: Reliable Software Releases Through Build, Test and Deployment Automation“ von Jez Humble und David Farley. Die beiden Autoren entschieden sich hier bewusst gegen den Begriff Continuous Deployment, da bei Continuous Delivery nicht automatisch in Produktion deployed wird. Continuous Deployment impliziert Continuous Delivery. Andersherum ist dies jedoch nicht der Fall.
Continuous Integration ist die schwächste Form der kontinuierlichen Entwicklung. Bei ihr werden alle Änderungen automatisch gebaut und getestet, es findet aber kein Deployment auf einem Server statt.
Continuous Deployment mit dem Cloudogu EcoSystem
Das Cloudogu EcoSystem unterstützt eine komplette Continuous Integration Pipeline. Um diese zu einer Continuous Deployment Pipeline auszubauen muss lediglich ein entsprechendes Deployment-Ziel konfiguriert werden. Die Grundvoraussetzung dafür ist, dass der Kunde Zugriff auf das Deployment-Ziel hat.
Im Cloudogu EcoSystem wird Jenkins als Build-Server benutzt. Eine beispielhafte Implementierung einer Continuous Delivery Pipeline wird in unserem Blog beschrieben: Von den Grundlagen der Jenkins Pipeline, über die Optimierung der Performance und hilfreichen Tools hin zur kompletten Pipeline.
