Softwareverteilung automatisieren: Continuous Delivery in der Praxis

Mit automatisierter Softwareauslieferung lassen sich Änderungen an Anwendungen schneller realisieren und Kunden mit gewünschten Funktionen versorgen.

Es gilt als das höchste Prinzip in der agilen Software-Entwicklung: Kunden durch das frühe und kontinuierliche Ausliefern wertvoller Software zufriedenzustellen. Dazu ist es notwendig, den Auslieferungsprozess zu automatisieren, um Features beziehungsweise dringend notwendige Änderungen schnellstmöglich den Benutzern in die Hände zu geben. Im globalen Wettbewerb kann die Umsetzung dieses Prinzips überlebenswichtig sein.

Martin Etmajer,
Technology Strategist,
Dynatrace

Da beim Ausliefern von Software gerade durch menschliches Einwirken einiges schief gehen kann, wird Continuous Delivery, der logischen Weiterentwicklung der agilen Entwicklungspraktik Continuous Integration (kontinuierliche Integration), weitestgehend automatisiert. 

Die Bereitstellung vollständiger Laufzeitumgebungen sowie das Ausrollen von Software auf Knopfdruck beschränkt sich dabei keineswegs auf die Produktion allein: Continuous Delivery soll sicherstellen, dass eine Anwendung wie erwartet funktioniert. Dafür wird die Software in einer gleichartigen, wenn auch nicht notwendigerweise identischen, Laufzeitumgebung getestet.

Hierbei sollen manuelle Prozesse ausgeschlossen werden, die durch folgende Kriterien geprägt sein können:

  • langsam, fehleranfällig, nicht wiederholbar und unzuverlässig;
  • nicht konsistent über die verschiedenen Umgebungen hinweg;
  • aufwändig durch umfangreiche Dokumentation, die jedoch selten in aktueller Form vorliegt;
  • intransparent, da sie üblicherweise nur von einigen wenigen Experten ausgeführt werden können.

Automatisierte Deployments ermöglichen die rasche sowie zuverlässige (Wieder-)Herstellung konsistenter Umgebungen für Entwicklung, Test und Produktion. Sie tragen wesentlich dazu bei, Fehler noch vor dem Go-Live zu erkennen und verkürzen gleichzeitig in Kombination mit agilen Entwicklungspraktiken die Lieferzeit für neue Funktionen (siehe Abbildung 1).

Die so erzielbare schnellere Marktreife ist heute für viele Unternehmen wichtig – im zunehmenden Wettbewerb meist sogar überlebenswichtig. Je schneller eine neue Funktion zur Verfügung steht, desto früher können Unternehmen davon profitieren beziehungsweise herausfinden, ob ein Feature bei seinen Kunden überhaupt ankommt.

Abbildung 1

Doch wie genau werden automatisierte Deployments im Rahmen von Continuous Delivery eingesetzt? Die Deployment Pipeline, das Herzstück von Continuous Delivery, ist eine automatisierte Implementierung des Build-, Deploy-, Test- und Release-Prozesses einer Anwendung und teilt diesen in unterschiedliche Etappen ein.

Das Konzept der „Pipeline“ ist dabei analog zu Lean Manufacturing: Beim Erkennen eines Fehlers wird die Produktionslinie sofort angehalten und das Problem mit der größten Sorgfalt gelöst. Nach der Korrektur wird die Wahrscheinlichkeit minimiert, dass sich dieser Fehler wiederholt. Dieses Prinzip des Continuous Improvements ist auch bei der agilen Softwareentwicklung von großer Bedeutung.

Deployment Pipeline in der Praxis

Die Deployment Pipeline wird angestoßen, sobald ein Entwickler Code in ein Software Repository eines Versionskontrollsystems einpflegt. Anschließend startet der Build Automation Server als Kontrollzentrum eine Abfolge von Etappen, in denen die Anwendung zunächst entwickelt wird, um danach diverse Arten automatisierter Tests durchzuführen, die den Build von unterschiedlichen Blickwinkeln auf korrekte Funktionsweise überprüfen – im Fehlerfall wird der Prozess abgebrochen. Nur wenn ein Build alle Prüfungen erfolgreich bestanden hat, besitzt er die nötige Voraussetzung für den produktiven Einsatz.

Etappe 1: Build

In einem ersten Schritt verschiebt der Build Automation Server eine Kopie des Quellcodes der Anwendung aus dem Software Repository in ein temporäres Verzeichnis, kompiliert den Code und führt erste umgebungsunabhängige Tests (zumeist Unit-Tests) aus. Anschließend werden Release-Artefakte wie Installer Packages umgewandelt und die Dokumentation erzeugt.

Etappe 2: Akzeptanztests

Zur Vorbereitung auf die Akzeptanztests werden Deployment-Automatisierungsskripts ausgeführt, die eine Laufzeitumgebung ähnlich der Produktivumgebung erzeugen. Nach Installation der Release-Artefakte prüfen automatisierte Smoke-Tests, ob die Anwendung und von ihr benötigte Services laufen. Schließlich verifizieren automatische Akzeptanztests, dass die Anwendung kritische, mit dem Kunden vereinbarte Akzeptanzkriterien erfüllt und somit tatsächlich Businessfunktionalität aus Sicht des Kunden zur Verfügung stellt (Abbildung 2).

Abbildung 2

Etappe 3: Kapazitätstests

Automatische Kapazitätstests zeigen, ob das System ein definiertes Service-Niveau unter produktionsähnlichen Lastbedingungen erreichen kann.

Etappe 4: Nutzerakzeptanztests

Als finalen Verifikationsschritt macht hier zumeist der Kunde manuelle Akzeptanztests, um die Funktionalität zu beurteilen.

Etappe 5: Release

Nach dem erfolgreichen Abschluss dieser Etappen werden die Release-Artefakte in einem binären Repository bereitgestellt. Sobald die Fachabteilung den Build freigibt, geht er in den produktiven Einsatz. Bei Continuous Delivery ist – im Gegensatz zu Continuous Deployment – der Release eines Builds in die Produktion immer noch ein halbautomatischer Prozess, der nur zwei Schritte erfordern soll: die Auswahl eines Builds aus einer Liste und das Drücken des Freigabeknopfes.

Infrastruktur als Code

Nach dem Release werden für die Produktionsumgebung die gleichen Deployment-Automatisierungsskripts ausgeführt, die auch zur Erstellung der produktionsähnlichen Test-Umgebungen verwendet wurden. Aufgrund der engen Beziehung zwischen Anwendung und Infrastruktur sollte dabei der Quellcode der Anwendung gemeinsam mit den Umgebungsspezifikationen, in Form der Deployment-Automatisierungsskripts, gewartet und in einem gemeinsamen Repository verwaltet werden.

Die Behandlung von Infrastruktur als Code erfordert sicher eine neue Sichtweise und damit eine gewisse Umgewöhnung, doch sie bietet auch eine große Chance: die Etablierung einer Kultur der Veränderung sowie der engen Zusammenarbeit zwischen Entwicklungs- und IT-Teams gemäß der DevOps-Methodik.

DevOps fördern mit automatisierten Deployments

Die Aktivitäten von Softwareentwicklungs-Teams werden im Allgemeinen von den Kundenanforderungen getrieben. 

Das Behandeln von Infrastruktur als Code ermöglicht es, die Automatisierung des Deployment-Prozesses als Engineering-Disziplin zu behandeln, angetrieben von den Anforderungen der sich ständig ändernden Software an seine Laufzeitumgebung: Zu Beginn einer Iteration definieren die Projektleiter der Entwicklungs- und IT-Teams in einem Planungs-Meeting die zu erledigenden Aufgaben.

Während der Iteration implementiert und testet jedes Team seine Aufgaben, bevor deren korrektes Verhalten vor einem größeren Publikum, vorzugsweise dem Kunden, demonstriert und verifiziert wird. In einem retrospektiven Meeting diskutieren die Teams, was gut und was nicht so gut gelaufen ist und wie die Zusammenarbeit verbessert werden kann.

Über die Durchsetzung eines automatisierten Auslieferungs-Prozesses und die damit verbundene Behandlung von Infrastruktur als Code lässt sich sicherstellen, dass funktionierender Code am Ende einer jeden Iteration steht, der schnell und zuverlässig für eine hohe Kundenzufriedenheit in ebenfalls funktionierende Laufzeitumgebungen ausgerollt werden kann.

Über den Autor:
Martin Etmajer ist Technology Strategist bei Dynatrace. Er hat einige Jahre Erfahrung als Softwarearchitekt sowie im Performance Monitoring und Management von hochverfügbaren Cluster-Umgebungen. In seiner jetzigen Position im Center of Excellence ist er an der Weiterentwicklung der Dynatrace Application Monitoring Lösung beteiligt und ein Experte für Performance Monitioring gemäß der Continuous Delivery Deployment Pipeline und DevOps. Sie können Martin Etmajer über Twitter via @metmajer kontaktieren.

Folgen Sie SearchEnterpriseSoftware.de auch auf Facebook, Twitter und Google+!

Artikel wurde zuletzt im Januar 2015 aktualisiert

Erfahren Sie mehr über Softwareentwicklung

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close