Schemagesteuerte Abläufe mit Config as Code

Das Problem

Abläufe für viele Märkte bedeuteten duplizierten Code und ein Engineering-Ticket jedes Mal, wenn Produkt oder Compliance eine regionale Regel ändern wollte.

Der Ansatz

• Formulare aus dem Schema rendern. Die Oberfläche liest JSON- oder YAML-Konfiguration über jsonform: Das Schema erzeugt Felder und Validierungsregeln. Eigene Aktionen, etwa das Starten einer nativen Brücke, bleiben im Code.
• Ein Schritt, unterschiedliche Ergebnisse. Die Konfiguration entscheidet, was ein Schritt je Markt und Plattform tut. Wo eine native Fähigkeit unterstützt wird, zeigt der Schritt eine Anleitung und eine Scan-Schaltfläche; sonst die normalen Formularfelder und eine Weiter-Schaltfläche. Das Produktteam ändert das in der Konfiguration, nicht im Code.
• Config as Code. Änderungen werden über Git eingereicht. Jede Änderung öffnet einen automatischen Pull Request und startet CI mit strikter Schemavalidierung, gestützt auf TypeScript-Typen, sodass fehlerhafte Konfiguration vor der Produktion scheitert.

Zwei Entscheidungen, die eine Erklärung verdienen

jsonform fürs Rendern, Code für Aktionen. Eine komplett servergesteuerte UI, die beliebige vom Server gesendete Logik ausführt, lädt zu Remote-Code-Execution-Risiken und Performanceproblemen ein. Datengetriebenes Rendern mit Aktionen, die an vorkompilierte Handler gebunden sind, bewahrt die Flexibilität ohne dieses Risiko.

Git statt Admin-Formular. Einfache Änderungen ohne Governance zerstören Produktionsabläufe. Pull Requests, Typprüfungen und CI machen jede Änderung nachvollziehbar, geprüft und leicht rückgängig zu machen.

Das Ergebnis

Konfigurations-Releases hängen nicht mehr von Frontend-Deployments ab, sodass Updates für mehrere Märkte von Wochen auf Stunden schrumpften und die regionale Code-Duplizierung nicht weiter wuchs.