Suche
Interview mit Andreas Gerst

DevOps: Mehr als nur Dev plus Ops

Redaktion JAXenter

©Shutterstock / Kalakruthi

Die Mauern zwischen Entwicklung und Betrieb niederreißen und mehr Austausch zwischen Entwicklern und Admins schaffen. Das ist die Grundidee hinter DevOps. Doch das setzt viel voraus, oft sogar einen Kulturwandel im gesamten Unternehmen. Denn wer auf DevOps setzt, bringt Menschen, Prozesse und Technologie unter einen Hut. Das gelingt nicht ohne die nötige Agilität, die starre, unflexible und langsame Prozesse ersetzt. Wie schwer das in der Praxis sein kann, weiß Andreas Gerst, CTO und Vice President für Presales, Central Europe bei CA Technologies.

Warum überhaupt DevOps?

Business Technology: Herr Gerst, wo sehen Sie die größten Vorteile von DevOps?

Die Time to Market wird durch DevOps deutlich kürzer.

Andreas Gerst: Heute wird das Business im Grunde an allen Stellen von Software gesteuert. Das gilt für alle Kontaktpunkte zum Kunden, für die Steuerung der Supply Chain und der Produktion, aber auch für Controlling und Finance. Was früher oft Silos mit begrenzten Schnittstellen waren, muss heute zu einer Einheit mit einem nahtlosen Datenfluss und schnellen Reaktionszeiten werden. Das wirkt sich auf Entwicklung und Einsatz von Software aus.

DevOps bedeutet ja zunächst einmal eine enge Integration der verschiedenen Bereiche im Softwarelebenszyklus Entwicklung, Testing und Produktion. Ziel ist es, diese drei Bereiche zu einer engeren und besseren Zusammenarbeit zu bringen, aber auch den gesamten Entwicklungs- und Betriebsprozess zu automatisieren. Der Vorteil dabei: höhere Geschwindigkeit für den End-to-End-Prozess. Neue Releases können schneller ausgerollt, neue Features schneller eingeführt werden. Das heißt, die Time to Market wird durch DevOps deutlich kürzer.

Wird DevOps mit den richtigen Werkzeugen und Methoden praktiziert, erhöht sich auch die Qualität der ausgerollten Software. So können beispielsweise Releases weitgehend automatisiert in Produktion gehen, Fehler schneller behoben und Ausfälle vermieden werden. Und letztendlich erhöht eine enge Zusammenarbeit zwischen Teams und Abteilungen auch die Produktivität und Innovationskraft im Unternehmen.

BT: Wie ist denn der Status bei CA Technologies? Wie sind die Teams strukturiert?

Gerst: Wir leben DevOps bereits in einer ganzen Reihe von Produktlinien. Nur: Die Einführung von DevOps ist ein kontinuierlicher Prozess, der sich über die Abteilungen hinweg ausbreitet. Besonders bei unseren SaaS-Angeboten haben wir gute Erfahrungen gemacht. Hier kommen die Vorteile von DevOps zum Tragen: Wir sind selbst für den Betrieb der Software verantwortlich, bringen laufend neue Features und neue Releases und profitieren damit sehr von der Automatisierung.

BT: Wie ist die Zusammenarbeit zwischen Dev und Ops bei den Kunden organisiert?

Gerst: Viele unserer Kunden haben ein Center of Excellence. Hier kommen Vertreter der verschiedenen Teams, Entwicklung, Testing, Infrastruktur und Betrieb, zusammen und betreuen die gesamte End-to-End-Pipeline. Sie sind dann dafür verantwortlich, dass die Standards definiert sind, der Prozess automatisiert abläuft und die Teams intensiv kommunizieren.

Sie beraten nicht nur, sondern stellen für die Releaseautomatisierung eine Art standardisierte Infrastruktur bereit, auf der die Teams aus Entwicklung, Testing und Betrieb die einzelnen Projekte realisieren können. Im übertragenen Sinne bauen die Center of Excellence die Gleise, auf denen die Züge von Dev und Ops fahren können.

Alternativ kann man auch auf Personen setzen – also im Ops-Team eine Schnittstelle definieren, einen Verantwortlichen, der mit den einzelnen Dev-Teams den Kontakt hält und sich mit ihnen abstimmt. In regelmäßigen Meetings mit den Entwicklern, Scrum-Teams und Produktverantwortlichen werden dann Standards definiert, wie die Releases und der End-to-End-Prozess ablaufen sollen.

Wie setzt man DevOps um?

BT: Was ist der entscheidende Faktor, wenn es um die erfolgreiche Umsetzung von DevOps geht?

DevOps braucht agile Methoden.

Gerst: Ganz klar Agilität: DevOps braucht agile Methoden. Ein automatisierter End-to-End-Prozess, in dem neu entstehende Software getestet und automatisiert in Produktion gesetzt werden kann, bringt schließlich nichts, wenn die Software gleichzeitig nach dem linearen Wasserfallmodell in festgelegten Phasen programmiert wird und das erste Ergebnis nach zwei Jahren herauskommt. Damit die Vorteile von DevOps und Continuous Delivery richtig zum Tragen kommen, müssen Unternehmen auch dort schnell sein, wo Software produziert und weiterentwickelt wird.

Das funktioniert nur mit agilen Entwicklungsmethoden. So hat man nach jedem Sprint oder Programminkrement – je nachdem, wie lange diese angesetzt sind – immer ein Produkt, das automatisiert getestet und auch tatsächlich in Produktion gebracht werden kann. Damit ist das Ziel agiler Entwicklung erreicht: Ein schnelles Ergebnis, das tatsächlich Mehrwert bringt, und viele kleinere Releases, statt wenigen großen.

BT: Was bedeutet das für die Teamstruktur?

Gerst: Wir haben unsere gesamte Struktur in der Produktentwicklung und im Produktmanagement auf Agile ausgerichtet. Wir arbeiten in der Entwicklung mit Scrum-Teams, deren Arbeit sich an Release Trains ausrichtet. Ein neues Feature ist zur Releasezeit entweder fertig oder kommt halt in das nächste Release.

Mehr zum Thema: Wie man sein Team für moderne Softwaresysteme fit macht

In jedem Team sind sowohl Entwickler, Product Owner als auch Testing-Verantwortliche vertreten. Darüber hinaus – und hier kommt DevOps ins Spiel – arbeiten die Scrum-Teams eng mit denjenigen zusammen, die die Anwendungen dann tatsächlich betreiben müssen. Hier werden übergreifende Teams gebildet, die das automatisierte Release Management verantworten.

BT: Wie lässt sich diese Struktur skalieren?

Gerst: Es geht sicherlich nicht nur darum, dass diejenigen Projektteams agil arbeiten, die einzelne Apps oder vielleicht auch nur Teile einer Anwendung entwickeln. Wenn Unternehmen in einem größeren Rahmen agil sein möchten, müssen sie zum Beispiel auch Budgets agil umschichten und ihre Entwicklung auf das ausrichten können, was für den Endkunden schnell einen Mehrwert erzeugt.

Dieses Prinzip nennt sich Agile at Scale und lässt sich mit mehreren Methoden und Frameworks umsetzen. Wir bei CA verwenden SAFe (Scaled Agile Framework). Auf der Produktentwicklungsebene sind wir schon längst agil aufgestellt. Nun sind wir dabei, das auf die nächste Ebene zu bringen und stellen uns Fragen wie: Wie richten wir das Unternehmen aus? Welche Themen wollen wir unseren Kunden in den nächsten ein bis zwei Jahren bieten? Dabei wollen wir den Kunden in den gesamten Prozess einbeziehen und nach genau definierten Vorgehensmodellen arbeiten.

Was ist DevOps-Kultur?

BT: Klingt, als würde DevOps einen Kulturwandel im gesamten Unternehmen hervorrufen.

Gerst: Absolut. Der Kulturwandel ist bei uns, aber auch bei vielen unserer Kunden, noch im Gange. Diesen Weg kann man nur gehen, wenn man bereit ist, mit hoher Geschwindigkeit zu arbeiten und in schnellen, automatisierten Schritten zu denken. Oft bedeutet das, dass man bewährte Methoden aufgeben muss.

Das A und O ist jedoch die Bereitschaft zur Zusammenarbeit.

Das A und O ist jedoch die Bereitschaft zur Zusammenarbeit. Wenn man die nicht hat, nützen auch die besten Tools nichts. Die bislang oft isoliert arbeitenden Teams aus Entwicklung, Testing, Betrieb und Infrastruktur müssen Vertrauen zueinander aufbauen und sich intensiv austauschen. Dies ist oft schwierig, weil die Arbeitsweisen und Historien der einzelnen Mitarbeiter und Teams teilweise sehr unterschiedlich sind. Organisationsformen wie Center of Excellence, automatisierte Prozesse, regelmäßige Meetings und vordefinierte Standards erfordern ein Umdenken.

Wir haben die Erfahrung gemacht, dass dies nur Top-down funktioniert: Das Management muss die Veränderung treiben und kontrollieren. Wird der Kulturwandel einfach nach unten delegiert, versandet er schnell im Alltagsstress, denn die Mitarbeiter sind bereits zur Genüge ausgelastet. Sie haben keine Zeit, sich zusätzlich mit Themen wie Continuous Delivery auseinanderzusetzen. Die Motivation und der Ansporn dazu müssen von außen kommen. Und so scheitern viele DevOps-Initiativen daran, dass sie lediglich als Add-on gesehen, aber nicht wirklich gelebt und vom Management getrieben werden.

Lesen Sie auch: 7 Antworten auf die Frage: Welche Werte gehören zur DevOps-Kultur?

BT: Veränderung bedeutet immer auch Skepsis. Wie fallen die Reaktionen in den Unternehmen aus, wenn sie auf DevOps umstellen?

Gerst: Die Reaktionen sind je nach Funktion der Mitarbeiter sehr unterschiedlich. Auf Entwicklerseite werden DevOps-Initiativen oft sehr positiv aufgenommen. Entwickler sind oft deshalb offener und aufgeschlossener, da sie sich durch lange Releasezyklen gebremst fühlen und gerne schneller arbeiten würden. Die Bedenken kommen eher aus den Bereichen Testing und Betrieb: Diese Teams sind dafür verantwortlich, dass Produkte tatsächlich und für den Kunden zufriedenstellend laufen. Da ist unserer Erfahrung nach die meiste Aufklärungs- und Überzeugungsarbeit zu leisten. Am einfachsten ist der Einstieg über Pilotprojekte, die nicht auf strategisch extrem wichtige Applikationen ausgerichtet sind. Hier kann an kleineren Produktbereichen ausprobiert werden, dass eine hohe Geschwindigkeit durchaus funktionieren kann – auch noch bei hoher Qualität.

DevOps Tools – die kleinen Helfer

BT: Welche Tools helfen bei der Umsetzung?

Gerst: Das wichtigste Element bei DevOps ist eine Automatisierung des End-to-End-Prozesses, von der ersten Zeile Code über das Testing bis hin zum laufenden Betrieb. Denn eine hohe Geschwindigkeit bei gleichzeitig hoher Qualität lässt sich nur durch eine vollständige Automatisierung erreichen, die vor allem auch das Testing mit einschließt. Das bedeutet, dass Prozesse schneller ablaufen und man jederzeit nachvollziehen kann, was, wie, wo und wann passiert.

Hier gibt es entsprechende Tools, die mithilfe definierter Prozesse die einzelnen Schritte begleiten: Der Code wird geschrieben, der dann die verschiedenen Testschritte durchläuft, paketiert wird und live geht. Gleichzeitig integrieren Release-Automation-Tools auch eine Rückkopplung an Testing und Entwicklung: Probleme in der Produktion oder Ergebnisse von Performancetests werden automatisch an die Entwickler und Tester gemeldet, die die Informationen dann aufbereitet zur Verfügung haben, um entsprechende Probleme zu beheben.

Mehr zum Thema: DevOps Tools: Vier Tool-Tipps von führenden DevOps-Experten

Natürlich gibt es auch entsprechende Werkzeuge ,z. B. für die Verifizierung der Codequalität, Servicevirtualisierung, für das Test Data Management, die Test-Case-Optimierung und fürs automatisierte (Performance) Testing.

BT: Was kommt zuerst: die Henne oder das Ei? Der Kulturwandel oder die Technologie? Wie beginnt man solche Projekte beim Kunden?

Gerst: Typischerweise beginnt man mit den Methoden, also mit der Kultur. Denn nur, weil man bestimmte Tools einführt, fangen die Leute noch lange nicht an, zusammenzuarbeiten. Deshalb gilt es zunächst, ein Bewusstsein für die organisatorischen Voraussetzungen zu schaffen, Silos abzubauen und den Austausch zwischen einzelnen Bereichen zu fördern. Oft richtet man ein Center of Excellence ein und implementiert regelmäßige Abstimmungsmeetings. Und man definiert, was man eigentlich erreichen möchte: Wie soll die Zusammenarbeit organisiert sein? Wo beginnen wir mit der Umstellung? In welchen Bereichen bringt DevOps am meisten Mehrwert?

Die Automatisierung über Tools erfolgt dann im nächsten Schritt. Dazu gehört natürlich auch, den Status quo im Unternehmen festzustellen. Gerade in den Testing-Abteilungen gibt es in der Regel ja schon sehr viele Tools, die es zu integrieren gilt, um tatsächlich End-to-End automatisieren zu können.

BT: Ist so ein Projekt jemals wirklich abgeschlossen?

Gerst: Die Idee hinter DevOps ist, dass man sich und seine Prozesse stetig optimiert. Insofern haben diese Projekte niemals wirklich ein Ende. Unsere Arbeit als Dienstleister ist dann beendet, wenn der Kunde selbst die entsprechende Kompetenz aufgebaut hat – beispielsweise im Rahmen eines Center of Excellence – und die Initiative intern skalieren kann. Gerade in einem größeren Unternehmen geht das Schritt für Schritt.

Je nach Priorität werden zunächst kleinere und schließlich auch größere Projekte angepasst. Nach einem erfolgreichen Pilotprojekt, von dem alle Beteiligten überzeugt sind, setzt man meist dort an, wo häufig geändert wird, also bei kundenorientierten Anwendungen wie etwa Mobile-Apps, bei denen großer Wettbewerbsdruck herrscht und man häufig auf äußere Bedingungen reagieren muss. Danach wird DevOps auf andere Ebenen ausgeweitet.

DevOps in Deutschland

BT: Wo ergibt DevOps Sinn und wo nicht?

Gerst: DevOps macht überall dort Sinn, wo oft und schnell geändert werden muss. Und das ist heutzutage an vielen Stellen und in allen Branchen der Fall. Was das heißt, machen uns die großen und bekannten Apps auf dem Smartphone vor: Hier wird sehr oft geändert, meist mit kleineren Updates, zusätzlichen Features oder neuen Buttons. Anregungen und Feedback der Endkunden über die Bewertungen werden in kürzester Zeit als Feature oder Bugfix umgesetzt.

Gerade bei mobilen Anwendungen, aber auch bei klassischen Webseiten macht man heute zwischen den seltenen komplett neuen Releases eine Vielzahl von kontinuierlichen Weiterentwicklungsschritten. Das fängt bei Taxiunternehmen und Verkehrsbetrieben an, geht über Fluggesellschaften, Banken und Shoppingportale. Es gibt keine Branche, die nicht schnell auf Änderungen im Markt reagieren und diese in Code gießen muss.

Lesen Sie auch: DevOps Stories: Technologie-Entscheidungen an der Basis treffen

Überall, wo heute Kundenkontakt hergestellt wird, ist Software im Spiel. Damit wird Code zum erfolgskritischen Faktor: Es darf auf keinen Fall zu Situationen kommen, in denen der Kunde unzufrieden ist, weil etwa eine App nicht oder mangelhaft funktioniert. Hier greift der Vorteil von DevOps, trotz schneller Releasezyklen eine hohe Qualität zu gewährleisten. Durch eine optimierte Abdeckung durch Test-Cases und automatisierte Testdurchführung kann idealerweise jeder mögliche Testfall auch tatsächlich getestet werden – damit wird das Testergebnis so vollständig und repräsentativ wie möglich.

BT: Wie weit ist Deutschland im internationalen Vergleich?

Gerst: In Deutschland ist DevOps ein brandaktuelles Thema. In der Umsetzung sind wir aber noch lange nicht so weit, wie sich das alle wünschen würden. Das zeigen auch aktuelle Studienergebnisse: 88 Prozent der deutschen Unternehmen halten DevOps und agile Methoden für erfolgsentscheidend bei der digitalen Transformation.

Das Bewusstsein für das Thema ist also da. Damit steht Deutschland im Vergleich mit anderen europäischen Ländern ganz oben. Aber bei der Umsetzung herrscht noch großer Nachholbedarf. Zwar haben 89 Prozent der Unternehmen DevOps in mindestens einem IT-Bereich implementiert, aber nur 40 Prozent nutzen das Konzept über die gesamte IT hinweg. Hier gilt es, schon jetzt die richtigen Weichen zu stellen, entsprechende Tools und Methoden zu integrieren und in den Unternehmen die notwendige Kompetenz aufzubauen.

Andreas Gerst ist CTO und Vice President für Presales Central Europe bei CA Technologies. In dieser Rolle verantwortet er über alle Produkte und Geschäftsbereiche hinweg die Presales-Consulting-Teams in der Region Zentraleuropa und nimmt regelmäßig an Kundenmeetings, Konferenzen und anderen Events teil.
Geschrieben von
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.