DZ BANK-Anwenderbericht: Schneller und flexibler dank DevOps

Der allgemeine Trend zur Digitalisierung resultiert auch im Bankenwesen nicht zuletzt in gestiegenen Anforderungen an Schnelligkeit und Flexibilität der IT. Darum setzen wir, wie etliche andere Finanzdienstleiter, auf DevOps. Dabei handelt es sich um einen Ansatz, der Softwareentwicklung und IT-Betrieb enger zusammenarbeiten lässt. Die Qualitätssicherung und Fachabteilungen werden einbezogen, um die Entwicklung und Auslieferung neuer Anwendungen zu beschleunigen, ohne dabei die Qualität zu gefährden.

von Dr. Henning Ehm, CFA, Head of DevOps DZ BANK

Für uns begann alles mit Schmerzen bei der Entwicklung und dem Release-Management. Es stand ein sehr großer Release-Wechsel bevor, der einer Neueinführung unseres zentralen Handelssystems gleichkam.

Mehr als 100 Entwickler und viele andere waren daran beteiligt. Wir haben schnell gemerkt, dass es schwierig ist, den Code mit unseren traditionellen Methoden nachvollziehbar, schnell und wiederholbar auf Testumgebungen zu installieren sowie Releases zu koordinieren. Wir haben also nach einer alternativen Methode gesucht. Unser erster Schritt Richtung DevOps war die Einführung eines eigenen, auf die Installationsbedürfnisse der DZ BANK (Website) zugeschnittenen Paketmanagers inklusive Paketformat.

Um dieses Paketformat den Entwicklern zur Verfügung zu stellen, haben wir zunächst die Open-Source-Version von Jenkins verwendet und dort einen zentralen und einheitlichen sogenannten Build-Job für alle Entwickler aufgesetzt. Dieser erlaubte es ihnen, mit wenigen Klicks Pakete zu bauen, die wir dann mit unserem eigenen Paketmanager ausliefern konnten.

Einfache Anfänge

Zu der Zeit wurden für den Release-Wechsel des Handelssystems eine dreistellige Anzahl an Test- und Entwicklungsumgebungen verwendet, auf denen mehr oder minder gleichzeitig Pakete installiert wurden, sodass die Entwickler die Chance hatten, möglichst schnell festzustellen, ob ihre Pakete fehlerfrei installierbar sind. Zudem war es den Entwicklern so möglich, erste Fachtests gezielt auf ihren Testumgebungen durchzuführen, um ihre Arbeiten zu validieren. Durch diesen „shift left“-Ansatz, gewannen die Entwickler bereits während der Implementierung des Codes das Vertrauen, dass die Qualität stimmt.

Dies hat nach anfänglichen Zweifeln nach und nach die Zufriedenheit der Entwickler gesteigert, zumal es nach der Implementierung auch zu spürbaren Steigerungen der Zuverlässigkeit, Geschwindigkeit und Qualität kam.”

Insgesamt haben wir unsere Entwicklung durch den neuen Ansatz deutlich beschleunigt, und auch die kontinuierliche Weiterentwicklung des Systems nach dem erfolgreichen Go Live 2017 vereinfacht.

Aufgrund dieses Erfolgs bei einem der wichtigsten Systeme der Bank haben wir uns entschlossen, das Ganze systematischer anzugehen und auszuweiten. So haben wir uns erstmals systematisch mit DevOps beschäftigt und nach weiteren Systemen auf dem Markt gesucht, die uns dabei unterstützen können.

Nach den erfolgreichen Anfängen haben wir im Team beschlossen „all in“ zu gehen und Continuous Integration / Continuous Delivery (CI/CD) konsequent einzusetzen.”

Weil Jenkins bereits die CI-Seite abdeckte, war dies gesetzt, besonders, weil viele Entwickler sich inzwischen gut damit auskannten. Die Herausforderung auf der CI-Seite bestand im Wesentlichen darin, dass nicht jeder Entwickler beziehungsweise jedes Entwicklungsteam seinen eigenen Jenkins-Controller hat, sondern alles auf einer standardisierten Plattform aufgebaut werden sollte. Auf der CD-Seite befanden sich die DevOps-Neulinge „auf der grünen Wiese“ und haben nach einer Plattformlösung gesucht, die es erlaubt, nicht nur wiederholbare und skalierbare Deployments durchzuführen, sondern diese auch in wohldefinierte, regulatorisch abgestimmte Release-Pipelines einzubetten – nachvollziehbar und transparent.

Lösung muss Rahmen geben

Wir haben uns Anfang 2019 für CloudBees entschieden, weil es diese Anforderungen am besten erfüllte. Zudem war uns wichtig, dass die Lösung zwar einen Rahmen bietet, uns aber auch eine gewisse Freiheit erhalten bleibt. Von zentraler Bedeutung für uns war das sehr detaillierte Rechtemanagement, weil wir als Finanzinstitut strengen Regularien unterliegen. Besonders gefallen hat uns der Ansatz eines Self-Service-Katalogs, über den wir unseren Kunden, also den Anwendungsmanagern, letztlich die Services einfach und standardisiert zur Verfügung stellen können. Die Einführung der CD-Plattform hat sowohl den Release-Schmerz als auch die Deployment-Schwierigkeiten, besonders in Produktivumgebungen, gelindert, indem ein Kreislauf geschaffen wurde:

 Von einer Anforderung zu einer Entwicklung, von der Entwicklung zu einem Paket und von dem Paket über ein Deployment auf einer Testumgebung hin zu einem Release, das dann in der Produktion endet.”

Dr. Henning Ehm, CFA, Head of DevOps bei der DZ BANK AG

Dadurch, dass es sich um wiederkehrende Prozesse handelt, werden diese immer wieder geprüft und validiert, und entsprechend korrigiert, falls nötig. Entwickler haben jetzt auch die Möglichkeit, selbstständig Umgebungen zu aktivieren oder einen Release-Prozess anzustoßen. Ein Entwickler wird nie den gesamten Flow bis in die Produktion durchführen können – das erlaubt die Funktionstrennung nicht. Aber er kann alles soweit vorbereiten, damit seine Kollegen mit einem Testverfahren den Code validieren und freigeben können, sodass dieser wiederum in die Produktivumgebung eingespielt werden kann. Das sind Möglichkeiten, die eine saubere CI/CD-Pipeline oder mehrere Pipelines erlauben. Durch die Zusammenarbeit von CI und CD werden die Abläufe gekoppelt und miteinander integriert.

Umdenken erforderlich

Die Einführung von CI/CD verlief aus technischer Sicht weitgehend problemlos. Die Herausforderungen auf unserer DevOps-Reise sind primär menschlicher Natur. Mit der Einführung von CI/CD, Testautomatisierung etc. ändern sich Arbeitsweisen und Zuständigkeiten. In Summe bedarf es einer Verhaltensänderung aller Beteiligten. Und die kann man nicht von einen auf den anderen Moment erreichen. Da muss man alle auf die Reise mitnehmen. Wir haben gesehen, dass es sehr hilfreich ist, den betroffenen Kollegen möglichst konkret zu zeigen, welche Vorteile sie persönlich haben, wenn sie sich auf die DevOps-Reise einlassen, und nicht abstrakt nur darüber argumentieren, wie der Bereich oder das Unternehmen als Ganzes davon profitieren, sondern was sie konkret jeden Tag davon haben, wenn sie CI/CD und Testautomatisierung nutzen.

Die Umstellung auf eine Plattformstrategie erfordert beispielsweise entsprechende Änderungen der Vorgehensweisen.”

So nutzen wir bei der DZ BANK eine zentrale CD-Plattform, auf der das DevOps-Team Funktionen bereitstellt. Der Deployment-Plan für eine konkrete Anwendung liegt allerdings weiterhin beim technischen Anwendungsmanager des konkreten Systems, der sich die Erstellung des Plans in den meisten Fällen erst einmal aneignen muss. Das DevOps-Team hilft ihm dabei, aber schlussendlich muss er lernen, ihn selbst zu pflegen. Das bedeutet auch, dass unsere hausinternen Kunden sich auf eine Vielzahl neuer Techniken einstellen müssen, die sie dann auch konsequent einsetzen, insbesondere im Fehlerfall.

Nicht zuletzt um den kontinuierlichen Lernprozess zu steuern oder einfach nur als Sparringspartner zur Verfügung zu stehen, haben wir die DevOps-Gruppe ins Leben gerufen.”

Die Herausforderung für unsere Kunden ist, dass sie gefühlt eine neue Programmiersprache lernen müssen. Früher war der Implementierungsplan so etwas wie eine Installationsanleitung, die schriftlich in Microsoft Word verfasst wurde. Heute arbeiten wir mit Implementierungen, die nachvollziehbar gemacht werden können. Das heißt, eine Installationsanleitung kann wie jede andere Codezeile auch in einem Versionskontrollsystem abgelegt und dem Softwareentwicklungsprozess unterworfen werden. Man kann also einen solchen Deployment-Plan jederzeit aus der Schublade ziehen. Und der ist dann getestet, nachvollziehbar abgelegt und auch rückwirkend für die nächsten zehn Jahre erreichbar.

Resultate

Man darf von DevOps nicht erwarten, dass sich Wunder ereignen. Es gibt nichts, das wir jetzt können, was wir vorher nicht schon konnten. Nur läuft jetzt alles, schneller, robuster und nachvollziehbarer. Vor der Einführung von CloudBees ging die Entwicklung nicht so leicht von der Hand und war nicht so schnell zu skalieren und in die Breite zu bringen, sondern hat viel mehr Interaktion und Absprachen zwischen den Akteuren gefordert. Die heutige Lösung erlaubt ein sehr schnelles Onboarding, eine sehr hohe Transparenz für alle Beteiligten, die Verantwortung für eine Applikation haben, sodass Änderungen an dieser Applikation nachvollziehbar, schnell und einfach umgesetzt werden können, zu jeder Tages- und Nachtzeit.

 

Durch die Einführung von CI/CD können wir in der DZ BANK auch die regulatorischen Anforderungen besser erfüllen, denen Banken seit der Finanzkrise 2008 zunehmend unterworfen sind. Durch die Beschleunigung der Entwicklungsprozesse können wir schneller auf den Markt reagieren und uns neuen Gegebenheiten anpassen. Durch die Standardisierung auf eine Plattform ist es nun auch viel einfacher, Mindeststandards für Sicherheit und Code-Qualität zu setzen und für Compliance und Nachvollziehbarkeit zu sorgen.

Auch auf den Arbeitsalltag hat CI/CD einen positiven Einfluss. Die Zufriedenheit unserer Kunden ist deutlich gestiegen.”

Das gilt nicht nur für die Kunden, die als Anwendungsverantwortliche arbeiten, sondern auch für die Nutzer der Software. Letztere sind vor allem begeistert, dass wir ihre Anforderungen schnell und zuverlässig umsetzen können. Die Stimmung in der ganzen Organisation hat sich verbessert und Fehler können wir jetzt früher erkennen, sodass es nicht zu Verstimmungen kommt, weil Fehler erst im Produktivbetrieb auftauchen.

Pläne

Noch wenden wir den DevOps-Ansatz nicht auf alle IT-Systeme und -Prozesse an. Unser DevOps-Fokus lässt sich mit drei Worten umschreiben: Integration, Skalierbarkeit und Adaption. Bei der Integration geht es um die Verknüpfung der CI/CD-Plattform mit dem Ökosystem, also unseren Ticket-Systemen für die Changes, das Anforderungsmanagement und den Entwicklungs-Workflow.

Zudem werden wir die Systeme für die Testautomatisierung integrieren.”

„Skalierung“ bedeutet in diesem Zusammenhang, dass wir so viele Systeme wie möglich auf die CI/CD-Plattform migrieren wollen. Unter dem Schlagwort „Adaption“ wollen wir nicht nur die Technik bauen, sondern auch kontinuierlich die Kollegen heranführen, die Technik sinnvoll zu nutzen, um eine hohe Entwicklungsgeschwindigkeit zu erreichen, die Effizienz zu steigern und letztlich viele der Schmerzen, die die Kollegen vorher hatten, dauerhaft zu beseitigen.

Ein Rat für den DevOps Pfad

Die Vorteile von DevOps haben sich herumgesprochen und viele Unternehmen planen einen entsprechenden Umstieg. Allen, die sich die Vorteile von DevOps zunutze machen wollen, kann ich nur raten, einfach anzufangen. Das kann die CI-Seite sein, das kann die CD-Seite sein, das kann die Testautomatisierung sein. Nehmt euch ein System mittlerer Komplexität vor, wo es einen gewissen Schmerz gibt, und fangt an, eines der Probleme zu lösen. Hangelt euch danach zum nächsten. Vergesst darüber hinaus nicht: Technik sind nur 50 % von DevOps, die andere Hälfte ist der Mensch.Dr. Henning Ehm, CFA, Head of DevOps DZ BANK