Wie DevOps zum Stahlwerk kam
Über die Entstehung moderner DevOps-Infrastruktur für die Softwareentwicklung der Salzgitter AG
Stefan Winkler und sein Team entwickeln fertigungsnahe Produktionssysteme für die Stahlproduktion der Salzgitter AG. Dabei setzen sie auf einen top-modernen Technologie-Stack und eine ausgefeilte DevOps-Infrastruktur für qualitativ hochwertige mobile Applikationen.
Das war nicht immer so. Vielmehr lief 2015 noch alles manuell und der Technologie-Stack kam eher eingestaubt daher. Seither haben Stefan und sein Team viel geleistet, maßgeblich getrieben vom eigenen hohen Qualitätsanspruch. Wie es dazu kam und was alles passierte, erzählt er hier im Interview mit Dr. Andreas Göb (Customer Success Lead, CQSE) und am 18. Januar live im CQSE Software Intelligence Talk [1]!
Andreas: Stefan, du und dein Team habt euch viel mit dem Thema Software-Qualität auseinandergesetzt, dabei gab es immer wieder Berührungspunkte und Zusammenarbeit mit uns und unserem Produkt Teamscale [2], aber ihr habt auch viel eigenständig gearbeitet. Wann habt ihr denn damit angefangen?
Stefan: 2015, also vor 7 Jahren, ging es los. Damals waren wir zu dritt und haben praktisch alles in Handarbeit gemacht.
Andreas: Was hat euch motiviert, euch hier weiterzuentwickeln?
Stefan: Wir brauchten eine technische Basis für industrielle mobile Applikationen und wollten die Plattform dafür bereitstellen. Dabei hatten wir hohe Ansprüche an uns selbst und das hat uns angetrieben.
Andreas: Und wie seid ihr da rangegangen?
Stefan: Mit dem Aufbau unserer DevOps-Infrastruktur haben wir 2017 losgelegt. Als erstes haben wir eine Continuous Integration (CI) aufgesetzt und Jira eingeführt. Außerdem haben wir unseren initialen Technologie-Stack festgelegt.
Andreas: Wie viele Personen wart ihr damals und wie groß war eure Codebasis? Das ist ja immer eine spannende Frage: Ab wann lohnt sich eine bestimmte Infrastruktur?
Stefan: Wir waren zu viert und hatten drei produktive Apps, plus ein neues Projekt basierend auf Webtechnologien. Unser Framework hatte damals etwa 80k Zeilen Code und die Apps 10-40k Zeilen. Für uns lohnt sich CI ab der ersten Zeile, statische Codeanalyse ab 5k Zeilen und Architekturanalyse ab 50k.
Andreas: Mit wachsendem Produktportfolio und neuen Technologien wird es ja auch immer wichtiger, an einem gemeinsamen Qualitätsverständnis und einheitlichen Regeln zu arbeiten. Habt ihr dafür etwas getan?
Stefan: Wir haben unsere erste Teamscale-Lizenz gekauft! Zunächst für Architekturanalyse, aber letztendlich auch, um externes Feedback zu unserer Codequalität zu bekommen. Teamscale bietet ja beides. Und wir haben dann gleich auch darauf geachtet, dass die Analysen in der IDE mit denen in Teamscale zusammenpassen.
Andreas: Ihr habt also viel an den Tools gearbeitet. Was hat sich denn gleichzeitig an den Prozessen getan?
Stefan: Wir haben gleich im Jahr darauf (2018) unsere Teamscale-Lizenz vergrößert, weil wir inzwischen sechs Personen waren. Gleichzeitig haben wir Scrum eingeführt und sind auf git und Feature-Branches umgestiegen. Als ihr dann Anfang 2019 (mit Teamscale 4.8) die Findings Badge für Merge Requests eingeführt habt, hat das perfekt gepasst, um die Analyseergebnisse näher zu den Entwicklerinnen und Entwicklern zu bringen.
Andreas: Und wie ging es mit eurer Infrastruktur weiter?
Stefan: Die lief derweil ziemlich rund und so hatten wir Kapazität für das nächste große Thema: Testautomatisierung. Am Anfang haben wir unsere Integrationstests manuell auf unseren zentralen Tomcat deployt. Da wurde schnell klar, dass das so nicht geht. Deshalb haben wir uns direkt vorgenommen, alle Tests in Containern abzubilden.
Andreas: Und ihr habt in dem Zuge – quasi im Self-Service – auch angefangen, unsere Test-Gap-Analyse (TGA) einzusetzen [3].
Stefan: Ja, die TGA ist uns quasi vor die Füße gefallen. Wir wollten sehen, welche Änderungen ungetestet durchrutschen. Die erforderlichen Coverage-Daten konnten wir einfach aus den laufenden Systemen abgreifen und schon hatten wir ein Sicherheitsnetz vor den Releases, das obendrein sogar auch für unseren Projektleiter verständlich war!
Andreas: Wer nutzt denn bei euch die TGA-Ergebnisse?
Stefan: Testen ist bei uns Aufgabe der Entwicklung. Allgemein nutzen Teamscale bei uns hauptsächlich die Entwicklerinnen und Entwickler.
Andreas: Jetzt hattet ihr viel Infrastruktur auf der grünen Wiese hochgezogen. Davon träumen ja immer alle. Gab es seither auch schon größere Änderungen an der Infrastruktur?
Stefan: Ja. An Weihnachten 2020 sind wir von Bitbucket mit Bamboo auf GitLab umgezogen. Das war unser Weihnachtsgeschenk an uns selbst (lacht).
Andreas: Jetzt habt ihr uns letztes Jahr (2021) für einen Audit beauftragt [4]. Wie passt denn das ins Bild einer jungen, top-modernen Infrastruktur und Codebasis?
Stefan: Erstmal war das fürs Ego: Wir denken, wir sind gut aufgestellt, aber hält das einer objektiven Beurteilung stand? Außerdem wollten wir unsere technologische Ausrichtung und Infrastruktur prüfen. Unser Framework ist ja über die Jahre gewachsen, inklusive verschiedener Technologiewechsel. Und zuletzt hatten wir Fragen rund um Lizenzkompatibilität bzw. License Infringement hinsichtlich Open-Source-Code und Bibliotheken.
Dabei ist – wenig überraschend – herausgekommen, dass auch bei uns nicht alles "heile Welt" ist. Zu den Herausforderungen, die der Audit identifiziert hat, zählen technische Altlasten und unvollständige Tests und unerprobte Skalierbarkeit.
Aber es gab auch viel Lob für unsere Arbeit: Für die gleichförmige Struktur und Konzepte in allen Anwendungen, das selbstmotivierte Team, den modernen und zukunftssicheren Technologie-Stack und nicht zuletzt unseren effektiven Entwicklungsprozess. Das hat uns sehr gefreut!
Andreas: Ok, ihr seid also bestens aufgestellt und habt die Kapazität, in immer weitere Fragestellungen einzusteigen und hier Lösungen zu suchen, die dann wieder in eure Infrastruktur Einzug halten. Kann man das so sagen?
Stefan: Ja.
Andreas: Wie sieht denn euer Status Quo aus?
Stefan: Wir sind inzwischen zwei Scrum-Teams mit insgesamt 16 Personen. Unser Teamscale analysiert 25 Apps. Insgesamt haben wir da einen Zustand erreicht, der sehr nah an eurem Zielbild von "Qualitätstürchen" liegt.
Andreas: Du meinst unser Zielbild, im laufenden Entwicklungsprozess möglichst schnell spezifisches Feedback hinsichtlich der Qualität zu bekommen und das über Merge Requests explizit im Prozess zu verankern?
Stefan: Genau. Die wichtigsten Bausteine sind für uns dabei Teamscales Merge-Request-Integration und unsere Deployment Approvals als explizite Checkpoints im Prozess.
Andreas: Vielen Dank, Stefan, dass du uns auf euren Weg durch die letzten 7 Jahren mitgenommen hast! Gibt es noch etwas, das du zum Abschluss sagen möchtest?
Stefan: Ich habe mir selbst viel mitgenommen aus Vorträgen und dem Erfahrungsaustausch auf eurem Software-Intelligence-Workshop (damals noch vor Ort). Und jetzt freut es mich, auf demselben Weg auch etwas weitergeben zu können.
Erfahren Sie mehr und beteiligen Sie sich an der Diskussion beim CQSE Software Intelligence Talk mit Stefan Winkler (Salzgitter DS) und Dr. Andreas Göb (Customer Success Lead, CQSE), am 18. Januar 2023, von 10:30-12 Uhr.
Registrieren Sie sich jetzt kostenlos, um live dabei zu sein (online) und im Nachgang die Aufzeichnung zu erhalten.