In welchem Projekt arbeitet ihr?
Michael: Wir sind zuständig für das Kundenportal eines Automobilherstellers, über das ich mich als Fahrzeughalter registrieren kann und das die Verwaltung und Konfiguration von Online-Diensten ermöglicht.
Welche Rolle bekleidet ihr im Projekt?
Matthias: Ich bin einer der Softwareentwickler in unserem Team und kümmere mich in erster Linie um das Backend und dessen System- und Applikationsarchitektur. Werden neue Fähigkeiten bzw. Komponenten benötigt, ist es meine Aufgabe zu evaluieren, welche Infrastruktur dafür bereits vorhanden ist und zu ermitteln, mit welchen Systemen kommuniziert werden muss – sowie die benötigten Komponenten zu entwickeln.
Michael: Ich bin eine Mischung aus Product Owner und Scrum Master. Als Scrum Master kümmere ich mich darum, ein Verständnis von den agilen Methoden Scrum und insbesondere SAFe und LeSS in unseren Teams zu schaffen. Zudem moderiere ich die Dailies und Retrospektiven und kümmere mich darum, die zwei internen Teams, die an diesem Projekt arbeiten, zu vernetzen. Die andere Hälfte meiner Arbeit besteht darin, die Stakeholder beim Kunden und ihre Anforderungen in Einklang zu bringen, und daraus ein schlüssiges Konzept zu erstellen.
Wie vernetzt man mehrere parallel arbeitende Teams?
Michael: Dafür verwenden wir ein sogenanntes „Scrum of Scrums“, wobei sich alle Scrum Master der einzelnen Teams verschiedener Firmen regelmäßig abstimmen. Die besondere Herausforderung dabei ist, dass ein Teil unseres Teams in Argentinien sitzt. Um in solch einer Konstellation ein einheitliches Verständnis zu schaffen, holen wir die neuen Kollegen aus Argentinien jeweils für drei Monate nach Deutschland, um sich hier in unsere Prozesse voll zu integrieren und über Pair Programming einen guten Wissenstransfer zu ermöglichen.
Aus Entwicklerperspektive: Was ist das Besondere an diesem Projekt?
Matthias: Das Projekt läuft eigentlich schon seit 6 Jahren. Zu diesem Zeitpunkt bestand das Portal aus einem monolithischen Softwarebündel. Gemeinsam mit dem Kunden haben wir beschlossen, an dem Zustand etwas zu ändern, um zukünftige Änderungen und weitere Features schneller umsetzen zu können. Daher kamen wir auf die Idee, die Software neu zu schneiden und in einzelnen Microservices umzusetzen.
Was bedeutet „Microservices“ in diesem Kontext?
Matthias: Microservices bezeichnen ein modernes Architekturparadigma, das Dienste kapselt und durch geringe Abhängigkeiten einzeln betreibbar macht. Unser Ziel ist es, komplexe Anforderungen in gut wartbare Software zu überführen.
Wie geht ihr dabei vor?
Matthias: Jeder Microservice besteht aus einer Spring Boot Applikation. Diese Applikation enthält lediglich den Code für die Business Logik sowie die umgebungsabhängige Konfiguration. Geteilte Komponenten, wie zum Beispiel die Anbindungen an verschiedene Backendsysteme werden aus einem von uns entwickelten Framework als Bibliotheken eingebunden. Der Vorteil dieser Methode ist, dass wir die auf diese Weise entstandenden Komponenten nicht nur untereinander, sondern auch mit Teams des Kunden teilen können. Eine Herausforderung besteht darin, dass die Software derzeit noch in zwei verschiedenen Versionen existiert.
Warum das denn?
Matthias: Das alte Portal wird gerade schrittweise von einer modernen Single-Page-Application abgelöst, welche mit REST-basierten Diensten kommuniziert. Beide Versionen werden derzeit allerdings noch parallel betrieben. Daher achten wir darauf, dass die neuen Dienste die bestehenden Implementierungen ablösen, ohne dass die Nutzbarkeit beeinträchtigt wird. Das Arbeiten mit dem Framework ermöglicht uns das schnelle Umsetzen von Änderungen. Dies verringert vor allem die Integrationsaufwände enorm.
Wie erfolgt der Zugriff auf die benötigten Komponenten des Frameworks?
Matthias: Die Abhängigkeiten auf die einzelnen Bibliotheken werden durch das Build-System Maven verwaltet. Die fertige Applikation wird im Rahmen des Build-Prozesses in ein Docker-Image gepackt. Die fertigen Images werden dann als Container in einem Kubernetes-Cluster bereitgestellt. Der Quellcode unserer Software wird in einem Git-Repository abgelegt. Der Jenkins-Buildserver kann dieses überwachen und setzt bei Änderungen automatisch eine generierte Pipeline in Gang. Diese kompiliert den Code und führt die automatisierten Tests sowie eine statische Codeanalyse auf Schwachstellen aus. Wenn die Qualitätskriterien erfüllt sind, wird das erzeugte Docker-Image in der Test- und Integrationsumgebung veröffentlicht. Der Vorteil an dem Verfahren ist, dass man die Änderungen am Code und ihre Auswirkungen innerhalb weniger Minuten sichtbar machen kann.
Michael: Ich liebe dieses Projekt, weil man immer über den Tellerrand hinausblicken muss. Dadurch, dass das Kunden-Portal eine Verknüpfung zu vielen anderen unserer Produkte hat (wie z.B. die zentrale Plattform und einige Dienste), reicht es nicht aus nur das eigene Projekt zu verstehen. Daher ist ein reger Austausch mit Kunden, anderen Dienstleistern sowie unseren Kollegen aus den anderen Projekten notwendig. Man lernt hier nie aus.
