Die neue Fließbandarbeit: Continuous Delivery im Banking

1. Oktober 2012Dr. Sebastian Kempken

Banken gelten gemeinhin als eher konservative Branche und werden insbesondere in der IT-Welt gerne als Beispiel dafür zitiert, dass vor Jahrzehnten geschaffene Strukturen und verwendete Technologien auch heute noch maßgeblich für Neuentwicklungen sein können. Die Ablösung vorhandener Systeme erfordert stets einen hohen Aufwand. Auch deren Weiterentwicklung erscheint manchmal schwerfällig und träge. Moderne Software-Entwicklungsmethoden können hier helfen.

Ein besonderer Aspekt ist die Komplexität der gesamten IT-Landschaft: Neben den Kernsystemen gibt es eine Reihe von kleineren Produkten und Projekten, die ineinander greifen und eine große Zahl von Abhängigkeiten untereinander aufweisen. Es erfordert einen hohen Aufwand, diese Projekte miteinander zu koordinieren, um an kritischen Punkten zu einem festen Zeitpunkt zu korrekten Ergebnissen zu kommen.

Bei einer klassischen Vorgehensweise ist es meist so, dass eine so gut wie fertig entwickelte Software beispielsweise erst gegen Ende eines Entwicklungszyklus mit anderen Software-Komponenten zusammengebracht wird. In dieser Situation zeigen sich Integrationsprobleme erst dann, wenn es fast schon zu spät ist, um sie zu beheben. Aus dieser Erfahrung heraus ist man zur „Continuous Integration“ übergegangen, bei der jede Änderung an der Code-Basis eines Projekts einen neuen Build auslöst, in dem alle Module zusammengeführt und möglichst automatisiert miteinander getestet werden. Eventuelle Integrationsprobleme treten also deutlich früher auf, wenn sie noch mit geringerem Aufwand behoben werden können, anstatt gegen Projektende zu teuren Verzögerungen zu führen.

Eine Fortführung dieses Ansatzes ist Continuous Delivery: Hierbei wird eine sogenannte Deployment Pipeline eingerichtet. Die einzelnen Arbeitsschritte werden wie an einem Fließband hintereinander ausgeführt. Jede Änderung an der Code-Basis führt potenziell zu einem neuen fertigen Produkt, welches auch potenziell in die Produktionsumgebung ausgebracht werden kann.

Deployment Pipeline nach Humble/Farley, "Continuous Delivery. Reliable Software Releases Through Build, Test, and Deployment Automation" (Addison-Wesley 2010).

Deployment Pipeline nach Humble/Farley, „Continuous Delivery. Reliable Software Releases Through Build, Test, and Deployment Automation“ (Addison-Wesley 2010)

Die einzelnen Schritte umfassen zunächst einen Build aller geänderten Module sowie eine Reihe automatisierter Tests, angefangen von den bereits genannten Unit- und Integrationstests, Code-Metriken zur Qualitätskontrolle über Lasttests bis hin zu automatisierten Abnahmetests. Werden diese bestanden, kann die Software in eine Staging-Umgebung ausgebracht werden, um auch manuell noch einmal auf Herz und Nieren geprüft und anschließend in die Produktionsumgebung befördert zu werden. Der manuelle Testaufwand ist dabei eher explorativ, konzentriert sich also auf die Funktion neuer Features.

Die Auswirkungen dieses Ansatzes sind immens:

Zunächst wird eine an Features orientierte Denkweise befördert: Jede neue Version soll nach Möglichkeit ein Mehr an Funktionalität bieten, dazu müssen alle notwendigen Routinen realisiert werden. Durch die kleineren Zyklen wird sinnlose Arbeit vermieden und man konzentriert sich in der Entwicklung auf Aspekte, die tatsächlich benötigt werden. Das eigentliche Release wird dadurch, dass man es deutlich öfter und mit deutlich geringeren Änderungen gegenüber der Vorversion durchführt, „geübt“ und damit zuverlässiger und das Risiko der Liveschaltung geringer. Im Idealfall werden stressige Wochenenden, an deren Ende „hoffentlich alles klappt“, durch einen Knopfdruck abgelöst, an dessen Ende das automatische Deployment steht.

Im Besonderen muss man bei neuen Anforderungen an ein Projekt nicht den nächsten klassischen Produktzyklus, der möglicherweise mehrere Monate umfasst, abwarten, sondern kann durch die entsprechende Automatisierung und den damit einhergehenden kurzen Durchlaufzeiten durch die Deployment Pipeline eine kleine notwendige Änderung schnell und zuverlässig in Produktion bringen.

Haben Sie Fragen zu Continuous Delivery oder führen Sie bereits Ihre Software-Entwicklungsprojekte mithilfe dieses Ansatzes durch? Ich freue mich auf den Austausch mit Ihnen.

Dr. Sebastian Kempken Dr. Sebastian Kempken ist Senior Software Engineer bei adesso und Teilnehmer des Architektenprogramms 2013. Seine Leidenschaften in der Softwareentwicklung liegen im Build Management und in der Systemintegration.
Artikel bewerten:
1 Star2 Stars3 Stars4 Stars5 Stars
Loading...

Kommentar hinzufügen:

Ihr Kommentar: