Product Engineering · OpenShift · Betrieb
Regulierte Engineering-Plattform
Ein Fachexperte gab Richtung und Prioritäten vor. Ich übersetzte sie in funktionierende Produktinkremente und übernahm die technische Kette bis in den Betrieb: React-Oberflächen, GraphQL-APIs, Identität und Rollen, Datenoperationen sowie die Auslieferung auf OpenShift.
Verantwortungsbereich
Vom Fachwunsch bis zum laufenden System
Ich verantwortete Produktoberfläche, Anwendung, Datenbetrieb und Auslieferung gemeinsam.
- 01ProduktoberflächeArbeitsabläufe mit dem Fachexperten iteriert
- 02Anwendung & APITypeScript, React, GraphQL, Identität und Rollen
- 03Daten & BetriebJobs, Storage, Status, Backup und Restore
- 04DeliveryAzure Pipelines, Argo CD und OpenShift
Verantwortung, die im System sichtbar ist
Meine Arbeit umfasste Produktcode, Delivery und Betrieb.
- Fortlaufende Verantwortung
- 16+ MonateNachweisbare Produkt- und Plattformarbeit im selben System seit Februar 2025.
- TypeScript-Workspaces
- 17Frontend, API, gemeinsam genutzte Bibliotheken und Werkzeuge unter einem Build-System.
- Applikations-Workloads
- 5Anwendungsdienste im gemeinsamen OpenShift-Auslieferungsprozess.
- Deployment-Stufen
- 3Getrennte GitOps-Konfigurationen für Entwicklung, Vorproduktion und Produktion.
Ein gewachsenes Engineering-Produkt
Die Plattform bildet anspruchsvolle fachliche Arbeitsabläufe ab. Produktoberflächen, GraphQL-APIs, ein umfangreiches Domänenmodell und mehrere Betriebsdienste waren über Jahre gewachsen.
Die Plattform brauchte außerdem einen zuverlässigen OpenShift-Auslieferungsprozess. Die fachliche Entwicklung lief weiter, deshalb mussten Produktarbeit und Plattformmodernisierung im selben Takt stattfinden.
Arbeitsmodell
Fachlicher Impuls, technisch vollständiger Stand
Der Kunde bestimmte Ergebnis und Priorität. Ich übernahm die Umsetzung durch Anwendung, Delivery und Betrieb.
Der Kunde bringt ein
- Fachwissen und gewünschtes Ergebnis
- Priorität und betriebliche Randbedingungen
- Feedback am funktionierenden Stand
Ich liefere
- Produktoberfläche und Backend-Verhalten
- Migration, Auslieferung und Betrieb
- Tests, technische Kontrollen und wartbaren Code
Der Kunde gab die Richtung vor. Ich lieferte den nächsten produktionsfähigen Stand.
Die Fachlichkeit und die Prioritäten kamen direkt vom Kunden. Ich zerlegte die gewünschte Änderung in umsetzbare Schritte und baute sie durch Frontend, Backend und Betrieb.
Wir prüften jeden funktionierenden Stand gemeinsam. Das Feedback bestimmte direkt den nächsten Schritt. So entstand die Lösung mit dem Kunden und blieb nah an seinem tatsächlichen Arbeitsablauf.
Ownership durch den ganzen Stack
Ich übersetzte den Fachwunsch in Architektur und Code, schloss die Lücken zwischen den Systemschichten selbst und brachte die Änderung bis in einen auslieferbaren Zustand.
Für die OpenShift-Kompatibilität passte ich Container-Images und Buildprozesse an, führte das Workspace-Buildsystem zusammen und verband Azure Pipelines, Helm und Argo CD zu einem nachvollziehbaren Release-Prozess.
Release-Prozess
Vier überprüfbare Schritte bis OpenShift
Der Release-Prozess verbindet Quellcodeänderungen, Qualitätskontrollen und versionierte Deployment-Konfiguration.
- 01
Änderung bauen
Azure Pipelines erzeugt reproduzierbare Anwendungsartefakte und Container-Images.
- 02
Qualität prüfen
Linting, Tests und Buildprüfungen stoppen fehlerhafte Stände vor der Auslieferung.
- 03
Deployment-Konfiguration versionieren
Helm-Konfiguration beschreibt Workloads und Abhängigkeiten je Deployment-Stufe.
- 04
Per GitOps ausrollen
Argo CD gleicht den freigegebenen Stand mit OpenShift ab.
Was daraus im Produkt entstand
Ich integrierte OIDC-SSO und Gruppen-Mapping in das Kernprodukt und eine weitere Produktoberfläche. Sichtbare Fehlerzustände erklärten den Anwendern fehlerhafte Konfigurationen.
Versions- und Laufzeitstatus wurden über vier Komponenten sichtbar. Für Neo4j entstanden sichere Backup- und Restore-Abläufe, ein automatisches Sicherheitsbackup vor dem Restore, ein operativer Notfallpfad und Integrationstests für Fehlerfälle.
Parallel entwickelte ich konkrete Produktfunktionen weiter: Jobverwaltung, Storage-Browser, nachvollziehbare Rollenquellen, sichtbare Änderungshistorien und die Grundlage für einen neuen tabellarischen Engineering-Arbeitsbereich.
Ergebnis
Die Plattform erhielt neue Produktfunktionen, während wir Auslieferung und Betrieb stabilisierten. Der Kunde behält Fachlichkeit und Prioritäten.
Ich bleibe für eine Engineering-Aufgabe verantwortlich, bis der Code gebaut, geprüft, auslieferbar und für das Team betreibbar ist. Wissen und Betriebsverantwortung bleiben im Kundenteam.
Brauchen Sie jemanden, der die technische Umsetzung übernimmt?
Beschreiben Sie Produkt, aktuelle Engstelle und gewünschtes Ergebnis. Ich prüfe, welchen technischen Verantwortungsbereich ich mit Ihrem Fachexperten bis in den Betrieb übernehmen kann.