Continuous Delivery

Eine Sammlung von Techniken, Prozessen und Werkzeugen, die den Softwareauslieferungsprozess (englisch: Deployment) verbessern. Ziel ist es, wesentlich schneller und zudem automatisiert “Mikro-Updates” ausliefern zu können, statt mehrere Updates zu Paketen zu kombinieren, die aufwendig getestet und dann manuell eingespielt werden müssen.

Continuous Delivery ermöglicht es, Software schneller und wesentlich zuverlässiger in Produktion zu bringen als bisher. Grundlage dafür ist eine Continuous-Delivery-Pipeline, die das Ausrollen der Software weitgehend automatisiert und so einen reproduzierbaren, risikoarmen Prozess für die Bereitstellung neuer Releases darstellt.

Die klassischen Methoden der Software-Entwicklung und -Pflege, die mit klar abgegrenzten Programmversionen und Release-Zyklen arbeiten, sind für bestimmte Anwendungsfälle heute nicht mehr geeignet: Bei einem Programm wie Word oder PowerPoint wurden in der Vergangenheit im Abstand mehrerer Jahre Hauptversionen veröffentlicht, bekannte Fehler gesammelt, intern zugewiesen, korrigiert, Patches entwickelt, manuell getestet und dann in zeitlichen Abständen zusammen mit anderen Fehlerkorrekturen im Paket als Minor-Updates ausgeliefert.

Dieser Prozess kostet viel Zeit; während dieser sind die Nutzer den Fehlern ausgesetzt, obwohl ggf. bereits eine Fehlerkorrektur existiert, aber erst später in einem Update-Paket ausgeliefert wird. Hinzu kommt, dass diese Updates von den Anwendern in der Regel gezielt installiert werden müssen, ein komplett automatisches Update der Software war klassisch schon deshalb nicht möglich, weil viele Systeme keine ständige Internet-Verbindung hatten, früher mussten Updates häufig sogar per CD, Diskette o.Ä. eingespielt werden. Kein Wunder also, wenn Fehlerkorrekturen nur als Pakete ausgeliefert wurden. Des Weiteren gab es zwischen den Hauptversionen sehr häufig “Feature-Freezes”, es wurden also keine neuen Funktionen mit den Update-Paketen ausgeliefert, sondern nur mit Upgrades, die die Software auf eine neue Hauptversion hievten.

Diese Vorgehen ist beispielsweise für Systeme, die ständig mit dem Internet verbunden sind oder gar auf Webservern laufen, nicht mehr geeignet. Hier müssen Fehler schnellstmöglich behoben werden, da sie ansonsten ein Sicherheitsrisiko bedeuten. Zudem ist bei solchen Systemen die Unterteilung in Major- und Minor-Releases mit Feature-Freezes kaum mehr relevant und das Update der Anwendungen soll möglichst zeitnah, automatisch und ohne Nutzerinteraktion erfolgen, gleichzeitig muss sichergestellt werden, dass Aktualisierungen die Funktionsfähigkeit des Systems nicht behindern.

Continuous Delivery hat genau diese Zielsetzung: Durch eine Optimierung des Software-Entwicklungsprozesses, automatisierte Testverfahren und das “kontinuierliche” Bereitstellen und Einspielen von “Mikro-Updates” werden Anwendungen laufend auf dem aktuellsten Stand gehalten. Dies ist beispielsweise bei E-Commerce-Systemen wichtig, aber auch bei allen SaaS-Anwendungen (Software as a Service), bei denen Wartungsfenster, in denen die Anwendung wegen anstehender Software-Updates nicht für die Nutzer verfügbar ist, kaum noch akzeptabel sind.

Da auch immer mehr große Softwareanbieter ihre Lösung als Abo-Modelle “in der Cloud” zur Verfügung stellen (z.B. Microsoft Office 365, Adobe Creative Cloud), werden Major-Releases, die früher in der Regel kostenpflichtige Upgrades bedeuteten, immer weniger wichtig: Der Kunde zahlt dafür, immer die aktuellste Software zur Verfügung zu haben. Wichtiger ist es für den Support eher, die Gewissheit zu haben, dass alle Nutzer mit der aktuellsten Version einer Software arbeiten.

Continuous Delivery bedeutet bei Amazon beispielsweise, dass durchschnittlich alle 12 Sekunden neue Mikro-Updates für die Websites des Unternehmens inklusive der Online-Shops weltweit ausgespielt werden. Neue Features können so auch gezielt getestet werden: So ist es möglich, eine neue Funktion oder ein geändertes Verhalten der Website nur für eine bestimmte Zielgruppe und einen begrenzten Zeitraum freizugeben und die Resultate automatisch mit der vorherigen Version zu vergleichen. Binnen 45 Sekunden kann so durch das hohe Nutzeraufkommen auf Amazon.com ein Feature an 5.000 Kunden getestet werden, ohne dass diese dies überhaupt bemerken. Continuous Delivery sorgt hier also nicht nur für eine rasche Fehlerbeseitigung, sondern erlaubt auch automatisierte Tests von neuen Funktionen im Live-Betrieb.

Um Continuous Delivery einzusetzen, müssen allerdings die Organisation der Software-Entwicklung, die Abläufe, die verwendeten Werkzeuge (beispielsweise für automatisierte Testverfahren und das Deployment, also die Auslieferung), aber auch die interne Struktur der Software selbst auf das Szenario abgestimmt werden. Monolithische Strukturen, die gegenseitige Abhängigkeiten bedeuten, sind Gift für ein Continuous Delivery. Vielmehr müssen sowohl die einzelnen Software-Module als auch die Entwickler möglichst unabhängig voneinander sein und über klare Schnittstellen verfügen, die die Abgrenzung und reibungslose Kommunikation mit anderen Stellen sicherstellen.