Continuous Delivery als grundlegender Ansatz in der Webentwicklung

Vorteile von Continuous Delivery und der Unterschied zu Continuous Deployment

In der Software-Entwicklung und auch im laufenden Software-Betrieb, zählt die effiziente Gestaltung des Prozesses zur Verteilung der Software, das Deployment, zu den wichtigsten Prozessen. Erstinstallationen oder Versionsupdates werden im Rahmen eines Deployments halbautomatisiert oder vollautomatisiert auf den jeweiligen Endgeräten, wie typischerweise Server, installiert und konfiguriert. Entsprechende Deployment Prozesse sind also auch für die Entwicklung von Websites und Online-Services von zentralem Interesse und sichern letztlich maßgeblich die Qualität der Entwicklungen.

Kontinuierliche Softwareverteilung

Welcher Deployment Ansatz der geeignete ist, hängt vom gesamten Setup der Entwicklung und vor allem der Art der zu entwickelnden Software ab. Cloud-basiert Online-Services, individuelle Geschäftsanwendungen oder IoT-Geräte bedürfen unterschiedlicher Herangehensweisen.

Vor allem kontinuierliche Ansätze haben sich bewährt, denn durch die Regelmäßigkeit können Fehler viel einfacher nachvollzogen und behoben werden. Längere Zeitspannen zwischen einzelnen Versionierungen machen es deutlich schwieriger, Probleme zu finden und zu fixen. Je nach Komplexität kann dies dann Entwicklungsprojekte aus dem Zeitplan werfen oder sogar gänzlich gefährden.

Kurz zusammengefasst: Continuous Integration vs. Continuous Delivery vs. Continuous Deployment

Drei teilweise aufeinander aufbauende Ansätze gehören zur aktuellen “Best Practice“.

• Continuous Integration Continuous Integration beschreibt eine Vorgehensweise, bei der Entwickler den geschriebenen Code mindestens einmal täglich in ein Shared Repository (z.B. Git Hub) laden. Der Code wird zum Bearbeiten ausgecheckt und jeder Check-In stößt eine Verifizierung durch eine automatische erstellte Version an (Build). Fehler können so schnell erkannt und kurzfristig behoben werden.
• Continuous Delivery Continuous Delivery beinhaltet ebenfalls das Erstellen (Build) und Testen von Änderungen und wird dann automatisch in einer nicht öffentlichen Staging-Umgebung implementiert. Das Deployment in das Livesystem wird jedoch manuell durchgeführt. Sämtlicher Code kann nach erfolgtem Test dann in einem gebündelten Release auch im produktiven System installiert werden. Dies geschieht praktisch nahtlos, sodass Endnutzer beim Einspielen eines neuen Builds nicht mit kurzzeitigen Systemausfällen konfrontiert werden.
• Continuous Deployment Die Anwendung von Continuous Deployment sieht vor, dass jede Änderung, die erfolgreich getestet und damit freigegeben wurde, automatisch, ohne manuellen Aufwand auch im Live-System implementiert wird. Dies kann je nach System durchaus mehrmals täglich passieren.

Continuous Integration bildet die Basis für sichere und zuverlässige Software Releases. Ob und in welchem Fall jedoch Continuous Deployment oder Continuous Delivery die Vorgehensweise der Wahl sein sollte, kommt auf die Rahmenbedingungen an.

Continuous Deployment kann nur dann sinnvoll eingesetzt werden, wenn der entwickelnden Organisation das System gehört oder sie direkten Zugriff darauf hat. Dies trifft vor allem auf lokale Umgebungen oder Cloud-Szenarien zu. Schwierig und kaum darstellbar ist der Prozess des Continuous Deployment für kundeneigene On-Site Infrastrukturen oder darin eingebettete Geräte, beispielsweise Drucker. Für solche Situationen kann jedoch Continuous Delivery problemlos angewendet werden, da Code zwar kontinuierlich geliefert wird, aber nur freigegebene Releases manuell im Livesystem installiert werden.

Wann eignet sich Continuous Deployment oder Continuous Delivery?

Im Fall der Drucker lässt sich die Anwendbarkeit von Continuous Delivery und Continuous Deployment verdeutlichen. Für die Verteilung von Druckertreibern wäre es sogar nahezu technisch unmöglich und in jedem Fall wirtschaftlich äußerst fragwürdig, mit Continuous Deployment mehrmals täglich Updates der Druckertreiber zu senden. Mit einem Continuous Delivery Ansatz kann dieses Szenario allerdings sehr gut funktionieren, da nur bewusst freigegebene Pakete als neues Release eines Druckertreibers verteilt werden. Bis zu einem gewissen Grad kann Continuous Delivery und die damit verbundenen regelmäßigen Updates auch dann noch angewendet werden, wenn die Treiber auf einem Datenträger versendet werden müssten.

Continuous Delivery Prozess für eine agile Entwicklung

Die kontinuierlichen Entwicklungsprozesse beseitigen die Diskrepanz zwischen der Zeit, die darauf verwendet wird, Änderungen umzusetzen und der Zeit, die dann wiederum benötigt wird, bis diese Änderungen in einem Produktivsystem live gesetzt werden. Die einfachsten Zeilen Code, die eventuell in ein paar Minuten geschrieben wurden, kommen aber erst Wochen später im produktiven Kundensystem an. Solche langen Deployment-Zyklen behindern eine agile Entwicklung. Schnelle Feedback-Schleifen sind bei großen Release-Intervallen und der Menge an Änderungen, die diese dann inkludieren nicht möglich. Der Kunde wartet sehr lange auf neue Funktionen oder Features und auch bei eventuell auftretenden Fehlern lässt sich deren Ursache schwieriger finden.

Der Continuous Delivery Ansatz kann alle oben genannten Problematiken durch nachvollziehbare Softwareverteilung beheben.

Continuous Delivery Prozess als essenzielle Basis in der Entwicklung

Natürlich hat auch Continuous Deployment seine Berechtigung, aber eben aufgrund der vollständigen Automation auch Limitierungen. Continuous Delivery stellt jedoch den grundlegenderen Prozess dar, da dieser umfassend in verschiedensten Szenarien und Umgebungen Anwendung finden kann.

Die Engmaschigkeit der Release-Intervalle gestaltet sich je Entwicklung unterschiedlich, denn nicht in jeder Situation ist es angebracht und wünschenswert, jeden freigegebenen Build in das Produktivsystem einzuspielen. Aber im Grundsatz sollte das Ziel eines Continuous Delivery Prozesses sein, so oft und so frühzeitig wie möglich, in das Livesystem zu spielen - durchaus mehrmals am Tag, falls dies möglich ist. Nur so können die Vorteile des kontinuierlichen Ansatzes auch genutzt werden: Minimierung des Release-Risikos und Verkürzung der Feedback-Schleife für die Entwicklung.

Wir setzen bei unseren Projekten intensiv auf einen für unsere Arbeitsweisen optimierten Continuous Delivery Pipeline. Damit steigern wir neben der Softwarequalität auch die Produktivität unserer Webentwickler. Ebenso relevant ist dieses Vorgehen aber auch für Kunden, da durch die ständige Verfügbarkeit einer Staging-Umgebung, jederzeit Tests im Rahmen einer nicht-öffentlichen, aber voll einsatzfähigen Anwendungs-Umgebung möglich sind.