Matthias Eggert

Seit wann arbeitest Du bei Qytera?

Bei Qytera bin ich jetzt seit Juli 2023.

Wie bist Du zum Bereich DevOps gekommen und was hat Dich daran fasziniert?

Zum Thema DevOps bzw. Automatisierung bin ich eher zufällig gekommen. Ich habe nach dem Studium eine sehr gut bezahlte Stelle bei Continental bekommen und zugegebenermaßen damals mehr auf die Attraktivität des Arbeitgebers im Allgemeinen geschaut, als auf die inhaltliche Beschreibung der Stelle selbst. Gelandet bin ich in der Software-Integration für die Entwicklung elektronischer Bremssteuergeräte (also die Entwicklung der gesamten Bremsfunktionen wie ABS, ESC, HSA, ...). Als Integrator war ich die Schnittstelle zwischen den Entwicklern, den Architekten, den SW-Projektleitern und der Tool-Entwicklung. Ich musste dafür sorgen, dass die Software entsprechend dem Projektplan mit den richtigen Tools auf die richtige Art und Weise in das bestehende Produkt integriert wurde, ohne etwas kaputt zu machen. Ich unterstützte also alle und führte dann kurze Smoke-Tests auf der Hardware durch, bevor es in den Fahrversuch ging. Und dann gab es plötzlich einen Punkt, an dem dieser Prozess nicht mehr funktionierte, und wir haben eine neue Abteilung “Continuous Deployment” gegründet.

Könntest Du uns einen Überblick über deinen beruflichen Werdegang geben und welche Schlüsselerfahrungen Dich besonders geprägt haben?

Dies war der Beginn eines neuen Projekts. Es sollte eine neue Version der Bremsensoftware geben, mit einer neuen Architektur und einem neuen Ansatz. Die Software sollte modularer und wiederverwendbarer werden. Man hatte sich aber entschieden, die Software nicht von Grund auf neu zu entwickeln, sondern die alte als Basis zu nehmen. Das führte zu viel Chaos in der Entwicklung und vor allem zu vielen Fehlern. In der Regel war es nicht mehr möglich, die Software ohne großen Aufwand fehlerfrei zu kompilieren oder zu linken. Deshalb hat das Management zunächst entschieden, dass Änderungen an der Software nur noch bis mittags eingepflegt werden dürfen, und dann mussten die Integratoren den Nachmittag nutzen, um die Fehler zu beheben. Das hat mich extrem genervt und ich habe versucht, viele Schritte zu automatisieren und habe dann an der ersten CI/CD-Lösung mitgearbeitet, um meinen eigenen Arbeitsaufwand zu reduzieren. Aus dieser Automatisierungsinitiative ist dann mit anderen Kollegen die bereits erwähnte neue Abteilung entstanden. In dieser Abteilung habe ich mehrere Jahre gearbeitet. Fähigkeiten und Tätigkeiten waren dann sogar über den Firmenwechsel hinweg relativ konstant.

Welche speziellen Fähigkeiten und Kenntnisse hast du im Laufe der Jahre entwickelt, die dich zu einem erfahrenen DevOps Engineer machen?

Wenn man Arbeitsabläufe verbessern will, gehört dazu aber nicht nur eine Automatisierung. Ich denke, ich hatte in den letzten Jahren verschiedene Fähigkeiten und Eigenschaften als nützlich erkannt und erlernt, die darüber hinausgehen. Die Wichtigsten Punkte sind:

• Automatisierung

• Qualitätssicherung

• Wiederverwendbarkeit

• Build-Systeme

• Monitoring

• Autonomie

• Vertrauen

Jetzt kann ich hier natürlich nicht über alles reden. Die technischen Aspekte habe ich schon ein wenig beleuchtet, deshalb jetzt zu den letzten beiden Punkten. Ich bin davon überzeugt, dass Vertrauen die wichtigste Eigenschaft von Teams überhaupt ist. Vertrauen schafft Zuversicht, schafft gleichzeitig Verantwortung, stärkt Synergien, ermöglicht selbstbestimmtes Handeln, führt zu kurzen Entscheidungswegen und all das führt am Ende zu hervorragenden Produkten. Wie man unschwer erkennen kann, sehe ich mich selbst als Agilist. Ich glaube fest daran, dass Vertrauen das A und O einer erfolgreichen Zusammenarbeit ist.

Worum geht es in Deinem Job als DevOps Engineer?

DevOps ist eine agile Arbeitsmethode. Meiner Meinung nach geht es bei DevOps darum, durch gemeinsame Prozesse und Software-Werkzeuge eine effektivere und effizientere Zusammenarbeit der Bereiche Softwareentwicklung (Dev), Systemadministratoren (Ops), aber auch Qualitätssicherung und der Nutzerschaft ermöglichen. DevOps ist also ein Mindset und kein Job. Nun ist Qytera keine klassische Software-Schmiede, sondern ein Beratungsunternehmen, das sich auf Softwaretests und Testprozesse spezialisiert hat. Man könnte sich fragen, woraus hier “Dev” oder “Ops” bestehen. Es gibt einige offensichtliche Überschneidungen, z.B. dass Softwaretests natürlich schon immer Teil meiner Automatisierungslandschaft waren und fast schon einen Kern bilden, aber es gibt auch versteckte Aspekte. Zum Beispiel habe ich die Produktverantwortung für QLoad, unsere hauseigene Performance-Testing-Lösung. Mit QLoad sind wir in der Lage, ein Kundensystem aus der Cloud heraus einer extrem hohen Last auszusetzen, um dessen Skalierbarkeit zu testen und zu analysieren. Beim Performancetesten finden sich DevOps-Aspekte sowohl in der Werkzeugentwicklung als auch in der Testdurchführung und -auswertung wieder. Und diese technischen Teile, gepaart mit einem allgemeinen agilen Mindset, machen für mich einen DevOps Engineer aus.

Welche Best Practices verfolgst du, um effektive Continuous Integration und Continuous Deployment (CI/CD)-Pipelines zu gewährleisten?

Um effektive Continuous Integration und Continuous Deployment (CI/CD) Pipelines zu gewährleisten, lege ich besonderen Wert auf die sorgfältige Planung und Implementierung von Build Tools und Automatisierungsstrategien. Mein Ziel ist es, CI/CD-Pipelines nicht als Komplettlösungen zu konzipieren, sondern vielmehr als effizienten "Klebstoff", der die verschiedenen Phasen der Softwareentwicklung zusammenhält und optimiert. Dabei strebe ich an, die Pipelines so schlank wie möglich zu halten, um die Geschwindigkeit und Effizienz der Entwicklungsprozesse zu maximieren. Das bedeutet, dass jede Aktion innerhalb der Pipeline ein klares Ziel hat und darauf ausgerichtet ist, Wartezeiten zu minimieren und die Feedbackschleife zu beschleunigen.

Eine weitere bewährte Methode ist die Auswahl und Verwendung leistungsstarker Build-Tools, die eine solide Grundlage für die Automatisierung bilden. Ich achte darauf, dass diese Tools nahtlos in CI/CD-Pipelines integriert sind und ein hohes Maß an Konfigurierbarkeit bieten, um den spezifischen Anforderungen verschiedener Projekte gerecht zu werden. Ich selbst arbeite an einem Open-Source-Build-System auf Basis von CMake (GitHub - avengineers/spl-core: Software Product Line (SPL) support for CMake), das sich im produktiven Einsatz befindet und volle Unterstützung für Software-Produktlinien bietet. Im Rahmen dieses Projekts habe ich sogar als Haupt-Autor ein wissenschaftliches Paper bei der internationalen Software-Produktlinien-Konferenz (SPLC) eingereicht und damit den Best-Paper-Award gewonnen (In three steps to software product lines | Proceedings of the 26th ACM International Systems and Software Product Line Conference - Volume A).

Die Bedeutung einer strategisch durchdachten CI/CD-Pipeline und der Einsatz von Automatisierung und Build-Tools sind Themen bzw. Best Practices, über die ich leidenschaftlich gerne spreche. Zu diesen Themen halte ich auch Vorträge auf Fachkonferenzen. Im Januar war ich auf den Code Days in München (Code Days 2024 | Programm), demnächst werde ich auf dem German Testing Day einen Vortrag zum Thema “Weniger Pipelines, Mehr Spaß!” (GTD 2024 | Programm ) halten. In meinem Vortrag werde ich Einblicke und Best Practices aus meiner langjährigen Erfahrung geben und diskutieren, wie durch die Optimierung von CI/CD-Pipelines und den gezielten Einsatz von Technologie die Softwarequalität gesteigert und Entwicklungszyklen verkürzt werden können.

Was motiviert Dich am meisten in deiner täglichen Arbeit?

In meiner täglichen Arbeit finde ich meine größte Motivation in dem dynamischen und innovativen Umfeld, das die Consultingwelt bietet. Nachdem ich mehrere Jahre in großen Konzernen gearbeitet habe, weiß ich, wie sich sich technologische Stagnation anfühlen kann. In einem solchen Umfeld sind die Prozesse oft eingefahren und man steht immer wieder vor den gleichen Herausforderungen, ohne dass ein wirklicher Fortschritt erkennbar ist. Diese Erfahrungen haben mir gezeigt, wie wichtig es ist, in einem Umfeld zu arbeiten, das Innovation und technologische Entwicklung fördert.

Der Wechsel in die Beratung war für mich ein entscheidender Wendepunkt. Plötzlich fand ich mich in einem Umfeld wieder, das von ständigem Lernen, Anpassungsfähigkeit und dem Streben nach Verbesserung geprägt ist. Hier können wir nur neue Aufträge generieren, wenn wir mit modernen Technologien vertraut sind oder uns nicht scheuen, neue Wege zu gehen. Es geht nicht darum, bestehende Produkte zu verbessern und aus einem vorhandenen Goldesel möglichst viel Profit zu schlagen. Wir sind gewissermaßen selbst das Produkt und müssen daher ständig an uns arbeiten. Und das können wir immer wieder neu tun, mit neuen Kunden, mit neuen Teams, mit neuen Voraussetzungen und Werkzeugen. So schafft man nicht nur wirtschaftlichen Erfolg für sein Unternehmen, sondern kann auch sein eigenes Profil in verschiedene Richtungen schärfen.

Wie hast Du als neues Teammitglied Qytera damals erlebt?

Als ich bei Qytera anfing, wurde ich sehr herzlich empfangen, was mir den Einstieg in das Unternehmen erleichterte und mir von Anfang an das Gefühl gab, dazuzugehören. Ein fester Bestandteil meiner Einarbeitung war die ISTQB Foundation Level (FL) Prüfung. Hier hatte ich bereits eine solide Basis und dementsprechend weniger Lernaufwand als andere. Aber allein der Grundgedanke, dies als einheitliche Ausbildung für jeden neuen Mitarbeiter zu nutzen und damit eine Schärfung der Sprache zu forcieren und ein einheitliches Grundwissen aufzubauen, finde ich eine coole Idee.

Darüber hinaus hatte ich das Glück, Teil eines Mentoring-Programms zu sein, das für mich persönlich eine enorme Bereicherung darstellte. Mein Mentor und mein fachlicher Ansprechpartner, die beide als die Besten auf ihrem Gebiet anerkannt sind, spielten eine entscheidende Rolle in meiner beruflichen Entwicklung bei Qytera. Dies hat mir geholfen, mich schnell in das Team zu integrieren und einen positiven Start bei Qytera zu haben.

Wie sieht es mit Weiterbildungs- und Zertifizierungsmöglichkeiten bei Qytera aus?

Ich habe auch einen Ausbildungsvertrag mit verschiedenen Punkten, was ich als eine wirklich tolle Möglichkeit sehe, von Anfang an einen Plan für weitere Ausbildungsschritte zu haben. Dazu gehören neben dem bereits erwähnten ISTQB FL: AWS Cloud Practitioner, JMeter (Performancetest) und API Testing (mit Postman). Abgesehen von den Zertifizierungen, die das Unternehmen anbietet, habe ich auch selbst die Initiative ergriffen, um mein Fachwissen zu erweitern, indem ich weitere Zertifikate wie Certified Jenkins Engineer, Certified Scrum Master und Git erworben habe. Einfach weil es mir Spaß gemacht hat. 
Darüber hinaus ermutigt Qytera seine Mitarbeiter aktiv dazu, an Open-Source-Projekten zu arbeiten. Bei Open-Source kann ich meine Expertise der ganzen Welt zeigen, hier geht das ohne komplizierte Firmenrichtlinien und NDAs. Beispielsweise habe ich gerade die erste Version eines JMeter Plugins veröffentlicht (GitHub - Qytera-Gmbh/JMeterHARImporterPlugin: A JMeter plugin that lets you select a HAR (HTTP Archive) file to import into JMeter) und werde in Zukunft weiter daran arbeiten.

Was fällt Dir als Erstes zur Zusammenarbeit im Qytera-Team ein?

Kunde: “Ihr seid 30% schneller als geplant.” - und ich war in dem Projekt