Code Quality Testing als DevOps-Stütze DevQOps – eine Frage der Qualität

DevOps-Strategien etablieren sich immer weiter, haben ihr volle Leistungsfähigkeit jedoch noch nicht zwingend erreicht. Was auf dem Weg zum nächsten Evolutionsschritt fehlt, ist der maximale Qualitätsanspruch. Willkommen im Zeitalter der DevQOps.

Anbieter zum Thema

Windhoff Group

Deutsche Telekom MMS GmbH

Die Denkrevolution des Agilen Manifests ist längst Standard einer jeden Entwicklungseinheit. Gleiches gilt für das einstige Hypethema DevOps. Längst hat auch der IT-Betrieb sich den darin vermittelten Themen der Agilität angenommen.

Völlig zurecht besteht der Anspruch, dass „Dev“, also die projektgetriebene Softwareentwicklung, und „Ops“, der serviceorientierte Betrieb, gemeinsam Verantwortung für ein Ergebnis übernehmen. Aber es geht auch um die damit verbundene Automatisierung, durch die immer bessere, innovative Tools und neue Rollen für Entwickler und System-Ingenieure entstehen.

Dabei ist das Thema Zusammenarbeit in der IT natürlich nicht erst mit DevOps entstanden. In erfolgreichen Organisationen war es schon immer relevant. Teamwork ist eine kulturelle Frage, die allerdings durch das zunehmende Tempo der digitalen Transformation extrem getrieben wird.

Neue Tools, neue Wege

Die Digitalisierung der letzten Jahre hat an verschiedensten Stellen Tool-Diskussionen ausgelöst und den Status Quo der vorhandenen Unternehmenskulturen zurecht in Frage gestellt. Neue, flexiblere Lösungen und rein digitale Unternehmen schrien nach einer neuen Art der Zusammenarbeit von Betrieb und Entwicklung, um in einem Markt im Umbruch nicht ins Hintertreffen zu geraten. DevOps war der natürliche Weg, um den neuen Aufgaben gewachsen zu sein.

In diesem Zuge transformieren DevOps-Strategien fast zwangsläufig große IT-Einheiten in kleinere, agilere Teams und schaffen so – wenn es dem Unternehmen gelingt, hierarchisch angelegte Denkweisen hinter sich zu lassen – Platz für Autonomie und Gestaltungsspielraum. Die Einführung von DevOps ist damit immer auch ein Change-Projekt, bei dem gerade neutrale Berater und ein unternehmensspezifisches DevOps-Reifegradmodell hilfreich sein können.

Vom Hype zur Selbstverständlichkeit

Kanban-Board, Kaizen oder Backlog sind für Ops längst keine fremden Welten mehr. Der Betrieb nutzt die agilen Basiswerkzeuge der Entwicklung zur Erleichterung der eigenen Arbeit. In Sprints werden übergreifende Aufgaben mit Anfordernden, Fachabteilungen und der Entwicklung abgearbeitet. Eine Übersetzung in die jeweils andere Welt entfällt und aufkommende Missverständnisse werden durch die zugrundeliegenden StandUps oder Dailys geklärt.

Dabei senkt das Unternehmen durch die verbesserte Zusammenarbeit nicht nur Kosten, es verringert auch die Reibungsverluste zwischen den einzelnen Teams. Ops ist von Anfang an auch Teil des Entwicklungsprozesses und wird nicht wie früher erst in letzter Instanz hinzugezogen.

Betriebsthemen wie Kompatibilität, Patches oder Firewall-Freischaltungen können dadurch frühzeitig adressiert werden. Im Schnitt sehen wir bei unseren Kunden so eine Reduzierung des Softwareentwicklungsaufwands von rund 20 Prozent – Zeit, die direkt in neue Projekte investiert werden kann.

Fällt damit ITIL – die IT Infrastructure Library der Ops-Kollegen weg? Nein, mit dem nun offiziell von Eigner Axelos kommunizierten Update werden die bestehenden Best Practices um die Themen Agilität, DevOps und digitale Transformation erweitert.

Qualitätsgarant

Ein essenzieller Bestandteil erfolgreicher und vor allem technisch hochwertiger DevOps-Umsetzungen ist eine sauber implementierte und standardisierte CI/CD-Pipeline-Lösung (Continuous Integration and Continuous Delivery). Sie garantiert die schnelle, stabile und fehlerfreie Code-Auslieferung bis hin zur Anwendung in Produktionsumgebung.

Vor allem sorgt sie aber auch für ein Gleichgewicht zwischen Dev und Ops, indem der Betrieb Teilhabe am Entwicklungsprozess bekommt und die Entwickler Einblicke in den 24/7-Betrieb oder zugrundeliegende Serverstrukturen erhalten. Letzten Endes ist die CI/CD-Pipeline auch der durchgehende Garant für die (automatisierbare) betriebliche Abnahme und damit die Erfüllung der Security- und Compliance-Richtlinien der Organisation.

Das Entwicklungsteam übernimmt im Sinne von „You Build it – you run it“ dabei generell mehr Verantwortung für die Verfügbarkeit der programmierten Anwendung im Produktionsbetrieb. Ops bildet seinerseits Fähigkeiten aus, Build- und Deployment-Prozesse als agile Services im Geiste der Entwicklungskollegen zu etablieren.

Wie der Name schon verrät, ist ein DevOps-Team idealerweise ein Mix aus Betriebs- und Testmitarbeitern sowie Softwareentwicklern und -architekten. Und auch der „Productowner" sollte Teil des Teams sein, damit die nötige, interne Kundennähe entsteht. Nur aus einem solchen Mix heraus kann es zur kontinuierlichen Weiterentwicklung der Anwendungs-Software als auch der CI/CD-Pipeline kommen.

Aber Vorsicht: Kundennahes Arbeiten erfordert Kommunikationsfähigkeit. Das Versteckspiel hinter Ops-Console oder Dev-Programmiercode ist damit passé. Stimmt die Kultur, verbessert sich das qualitative Ergebnis enorm.

Was braucht es aber, um die CI/CD-Pipeline derart hochwertig zu erstellen und auf Geschäftsbedürfnisse anzupassen? Insbesondere im OpenSource-Bereich ist oftmals Jenkins der Träger einer CI/CD-Pipeline. Für Jenkins sprechen die hohe Anzahl an PlugIns sowie der außerordentlich hohe Community-Support und der Einsatz in vielen kommerzielle Unternehmen.

Dabei dient das Software-System auch zur Ansteuerung anderer Tools, die ebenfalls beherrscht werden müssen: Zur Codeverwaltung etwa SVN oder Git, zur Builderstellung Maven, sowie Puppet, Chef oder Ansible zur Software-Auslieferung auf dem Server. Insgesamt tummeln sich in diesem Bereich über 80 Tools.

Doch Jenkins droht die Konkurrenz aus der Cloud. Azure DevOps greift hier beispielsweise bereits nach der Krone. Die Entscheidung dahingehend sollte beim DevOps-Team liegen, sei es zugunsten eines Shift & Lift der CI/CD-Pipeline, einer teilweisen Migration (CI mit Jenkins, Azure DevOps für CD) oder eines nativen Ansatzes. Bei allen Varianten ist Kubernetes aktuell jedoch nicht mehr wegzudenken.

Ein „Q“, das für die Grundwerte steht

Olaf Garves

Damit aus DevOps aber schlussendlich echte „DevQOps“ werden, müssen in die CI/CD-Pipeline entsprechende Tests – wie Funktionstests, Last- und Performancetests sowie Code-Quality- und Security-Tests – integriert sein. Das „Q“, die Qualität, steht dann vor allem für Sicherheit und Stabilität nach außen. Es steht damit für die Grundwerte der DevOps-Philosophie.

* Über den Autor

Olaf Garves leitet die Abteilung Application Management Telco und Mobility Solutions bei T-Systems Multimedia Solutions (MMS). Nach Tätigkeiten in der Hochschullehre, -forschung und freier Tätigkeiten begann er 1996 als Projektleiter in der MMS im Umfeld iTV und Bildtelefonie und führte anschließend auch mehrere Jahre eine SW-Entwicklungseinheit für webbasierte Lösungen.

2003 setzte er den Grundstein für eine Support-Abteilung, die erfolgreich Web-Lösungen für verschiedenste Kunden betreut. ITIL war dabei der rote Faden zur Gestaltung kundenorientierter Servicestrukturen. Seit 2013 beschäftigt er sich auch mit DevOps und hat seinen Bereich entsprechend agiler Anforderungen organisatorisch und prozessual weiterentwickelt. Dabei steht die Mitarbeiterförderung ganz vorne im Fokus. Garves ist im Beirat des itSMF und beteiligt sich aktiv in der DevOps Community der T-Systems MMS.

(ID:45894580)