DevOps / Testmanagement

Experten im Gespräch zu DevOps und Testinfrastruktur-Management

„Ich will ja nur eine stabile Testumgebung haben, mit aktuellen Versionen arbeiten und nicht mit jenen vor zwei Wochen!“. Geht es Ihnen manchmal auch so? In diesen und ähnlichen Situationen begegnen mir in letzter Zeit vermehrt Begriffe wie DevOps, Testumgebungsmanagement und Infrastrukturmanagement. Steckt darin tatsächlich die Lösung für diese Anforderung?

In der Literatur wird DevOps unter anderem als „agiles IT delivery“ beschrieben und mit dem „Continous Deployment“-Ansatz in Verbindung gebracht. Es steht aber auch – um nicht zu sagen vor allem – für den Wandel in der IT-Unternehmenskultur im Sinne bereichsübergreifender Kollaboration.

Das ist mir zu wenig greifbar. Ich möchte wissen, was es damit wirklich auf sich hat und inwieweit DevOps meinen Testalltag betrifft oder gar erleichtern kann. Darum frage ich zwei meiner ANECON-Kollegen die es wissen müssen: Siegfried Tanczos, Senior Testmanager mit Erfahrung bei Projekten mit komplexem Systemumfeld und Dietmar Berchtold, unser Vorreiter wenn es um neue Infrastruktur- und Integrations-Anforderungen sowie Werkzeuge geht.

 

Das Interview zu DevOps und Testinfrastrukturmanagement

Experten im Gespräch zu DevOps und Testinfrastrukturmanagement

Ursula Mayer-Schwalb>  Ich beschäftige mich seit über 20 Jahren mit Software-Test und stoße in letzter Zeit vermehrt auf die Begriffe „DevOps“ und „Testinfrastruktur-Management“. Sind das nur neue Worte für alte Hüte oder tatsächlich neue Themen?

Dietmar Berchtold> Wir befinden uns im Wandel. Die geforderte steigende Geschwindigkeit und Frequenz von Deployments und die neuen Möglichkeiten moderner Technologien führen zu einem geänderten Umgang mit Deliveries. Demnach geht es um den Umgang mit neuen Themen.

Ursula Mayer-Schwalb>  Woran kann eine Organisation erkennen, wie gut ihre Prozesse an diese steigende Geschwindigkeit angepasst sind?

Dietmar Berchtold> Ein mögliches Beispiel um zu messen, wie fortgeschritten eine Organisation bereits ist, lautet wie folgt: „Wenn ich nur eine Zeile Code ändere – wie lange braucht es, bis diese Änderung in Produktion und damit beim Enduser landet?“ Ich meine hier innerhalb des wohldefinierten und  qualitätsgesicherten Prozesses und nicht als „quick and dirty-Lösung“.

Ursula Mayer-Schwalb>  Wenn ich das richtig verstehe verändert sich die Welt in der IT und im Test gerade in Richtung häufigere und kürzere Lieferzyklen. Wo führt das hin?

Dietmar Berchtold> Die Frequenz der Lieferzyklen wird definitv höher. Früher gab es zwei bis vier mal im Jahr neue Releases, definierte Quality Gates für Test und Abnahme und fixe Taktung in größeren Zeitspannen. Manuelle Schritte beim Installieren und Bereitstellen waren normal und über einen langen Zeitraum hinweg planbar. Heutzutage konfrontiert uns die agile Entwicklung mit einigen Herausforderungen, wenn es um die Bereitstellung von Entwicklungs- Test- und Produktionsumgebungen geht. Das gilt nicht nur für die eigene Entwicklung – auch 3rd Party Komponenten, also zugekaufte Software-Lösungen – erfordern rasches Handeln, wenn es z.B. um das Einspielen oder Verteilen von Security-Updates, systemübergreifender Java-Updates und dergleichen geht.

 

Ursula Mayer-Schwalb>  Ist „DevOps“ also ein rein technisches Thema oder geht es auch um die Organisation?

Dietmar Berchtold> Ja natürlich – auch organisatorisch. Das zeigt schon die Wortzusammensetzung aus Development und Operations. Es gibt auch Widerstände – schließlich ist es eine viel engere Art der bereichsübergreifenden Zusammenarbeit. Prozesse müssen verschränkt und angepasst werden – Stichwort „Continuous Deployment“. Es muss in den Köpfen der Beteiligten erst ankommen, dass Deployment und Delivery Teile des Produkts sind und in diesem Sinn auch dem gleichen Lifecycle und der Qualitätssicherung unterliegen. „Infrastructure as a Code“ ist ein Mindset. Keine manuelle Tätigkeit mehr sondern automatisiert, definiert, strukturiert und vor allem transparent.

Ursula Mayer-Schwalb>  Heißt das, die Operatoren verlieren jetzt ihre Jobs?

Siegfried Tanczos>  Mitnichten! Der Job wird sogar aufgewertet und lässt mehr Raum zur Gestaltung. Das Risiko ist geringer weil nicht zwei große Brocken im Jahr ohne Netz und Seil produktiv zu setzen sind, sondern weil laufend überschaubare, jederzeit nachvollziehbare „Häppchen“ serviert werden.

Dietmar Berchtold> Dazu gibt es den Spruch „if it hurts do it more often“: das Leiden großer manueller Deployments – im Sinne von Aufwand, Kosten und Risiko – nicht hinauszögern, sondern öfters durchführen, laufend lernen und schrittweise verbessern. Also ein Prozess wie wir ihn aus der agilen Entwicklung kennen.

Ursula Mayer-Schwalb>  Was heißt das für den Software-Test?

Siegfried Tanczos>  Agilität bedeutet eine höhere Schlagzahl, kürzere Zyklen, engere Zusammenarbeit mit Entwicklung und Betrieb. Bereits bei der Bestückung der Testumgebung sollte der Deploymentprozess gleich so sein wie später bei der Produktivsetzung. Also wird auch der Deployment Prozess qualitätsgesichert. Im Test ist also zusätzliches Know-how gefordert, um diese Art des Tests zu organisieren und auszuführen. Fehlende Files, falsche Konfigurationen und dergleichen sind nun auch Fehler, die der Test findet. Das Resultat ist eine bessere Qualität und auch geprüfte Installationsanleitungen für den Betrieb.

Dietmar Berchtold> Idealerweise lässt sich diese Installationsanleitung gleich auch ausführen – inkl. Beachtung der richtigen Reihenfolge, ggf. Vorbereitung von Systemen, setzen von Environment Settings, usw.. In einer heilen Welt verwenden Development, Test und Produktion gleiche Maschinen und bestücken diese auf dieselbe Art.

Ursula Mayer-Schwalb>  Aber auf Produktivumgebungen gelten oft andere Regeln als in Testumgebungen. Wie sollen wir damit umgehen?

Siegfried Tanczos>  Auch diese Regeln, Scripte usw. nehmen Einfluss auf die Funktion des Gesamtsystems und sind entsprechend zu berücksichtigen und im Sinne der Qualitätssicherung zu testen. Betriebliche Anforderungen sind ja weitgehend nicht-funktionale Anforderungen an die Software und somit auch als solche zu behandeln. Die Unterschiede zwischen den System-Umgebungen sind durchaus üblich und sinnvoll, sollen aber bekannt und definiert sein. Z.B. eine Payment-Provider Anbindung: Diese ist in der Development-Umgebung – und vermutlich auch in der Testumgebung – nicht vorhanden.

Dietmar Berchtold> Dafür setzen wir z.B. virtualisierte Services ein. Die Konfiguration steuert, ob und welches System virtualisiert oder real angebunden wird. Diese umgebungsabhängige Konfiguration muss identifiziert und transparent zur Verfügung stehen. Dies erfolgt zentral, ist  nachvollziehbar änderbar und versioniert (z.B. über ein Source Control System). In der Deployment Pipeline sehe ich sofort wie weit ein Build gegangen ist. Ein erfolgreiches Deplomyent kann automatisierte Smoketests auslösen und dabei unterstützen, ein fertiges Software-Produkt zum Test bereit zu stellen.

 

Ursula Mayer-Schwalb> Das klingt alles sehr herausfordernd für IT-Mitarbeiter. Die Technik lässt sich ja schulen, aber für so einen „Kulturwandel“ braucht es noch mehr, oder?

Siegfried Tanczos>  Ja, eindeutig! Hier geht es vor allem auch um neue Rollen, Aufgaben und Zuständigkeiten. Es kommen neue Aufgaben hinzu, einiges fällt weg oder ändert sich. Die Abstimmung der Tätigkeiten und Zuständigkeiten ist eine sehr spannende Aufgabe, die nicht zu unterschätzen ist. Change-Management ist hier sehr gefragt und für einen erfolgreichen (Kultur-)Wandel unabkömmlich.

Ursula Mayer-Schwalb>  Gibt es etwas, das Ihr jenen noch mitgeben wollt, die gerade beginnen, sich mit dem Thema zu beschäftigen oder vielleicht durch die Transformation in die Agilität gerade mittendrin sind und sich eben dessen bewusst werden?

Siegfried Tanczos> „Gut Ding braucht Weile – Veränderung ebenfalls“. Es wird nicht alles von Anfang an und reibungslos funktionieren, aber kontinuierliches Lernen sowie das „besser werden wollen“ führen letztendlich zum Erfolg. Ein gut aufeinander abgestimmtes Team ist ein weiterer wesentlicher Erfolgsfaktor, den ich in vielen Projekten beobachte.

Dietmar Berchtold> Es ist wichtig, alle Bereiche von Anfang an miteinzubeziehen und auch deren Bedenken ernst zu nehmen, z.B. Security, Performance, etc.. Ich rate meinen Kunden, nicht alle Probleme sofort lösen zu wollen, sondern zu Beginn jene Themen anzugehen, die leicht zu lösen sind und zu frühen Erfolgen führen. Oder sich jenen Themen zu widmen, die immer wieder Probleme verursachen und große Wirkung zeigen. Eine Transformation ist kein Sprint sondern ein Marathon.

Ursula Mayer-Schwalb>  Vielen Dank an euch beide für das aufschlussreiche Gespräch!

 

„If it hurts, do it more often“

Haben Sie diesen Sager im Zusammenhang mit Releasezyklen, DevOps und Continuous Delivery auch schon gehört oder gelesen? Es bedeutet so viel wie: Raus aus der Komfortzone und dort besser werden, wo Scheitern keine Option ist!

Wie stehen Sie zu diesem Thema? Ich freue mich auf Ihre Meinungen, persönlichen Erfahrungen und Diskussionsbeiträge als Kommentar.

 

 

Passende Artikel

Antwort schreiben

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*