Die Einführung von geteiltem Code kann zwar Duplikate beseitigen, aber auch Kopplungen verursachen, die den Release-Flow behindern. In dieser Session zeige ich, wie Sie mit OpenRewrite DataTable und benutzerdefinierten Rezepten Abhängigkeiten zwischen Hunderten von Komponenten extrahieren und den „Metro-Plan“ Ihrer Release-Trains visualisieren können. Lernen Sie, wie diese Erkenntnisse in die CI/CD-Orchestrierung und interne Entwicklerplattformen einfließen können, um Entwicklern klare Abhängigkeiten und reibungslose Releases zu ermöglichen.

Zielpublikum: Architekten, Entwickler, DevOps Engineers
Voraussetzungen:Wissen über Dependency Hell, komplexe Release-Prozesse
Level: Practicing

Extended Abstract:
Softwareentwicklerteams haben aus guten Gründen eine Abneigung gegen duplizierten Code. Die Einführung gemeinsamer Bibliotheken ist in solchen Situationen ein gängiges Mittel, aber wie jedes Mittel hat auch gemeinsamer Code unbeabsichtigte Folgen: Er führt zu einer Kopplung zwischen Komponenten und macht eine Release-Planung zwingend erforderlich.

Durch die Analyse komplexer mehrschichtiger Abhängigkeiten zwischen Ihren Komponenten können Sie die benötigten Informationen extrahieren und den Metro-Plan Ihres Release-Trains konkretisieren. Mit der DataTable-Funktion von OpenRewrite lassen sich diese Informationen einfach extrahieren und visualisieren. Darüber hinaus sind diese Analysen mit OpenRewrite für Hunderte von Verbindungen effizient skalierbar, sodass sie sich perfekt für komplexe Codebasen mit vielen voneinander abhängigen Komponenten eignen.

In dieser Session zeige ich Ihnen, wie Sie DataTable und OpenRewrite-Rezepte nutzen können, um Ihre Codebasis abzufragen und wertvolle Einblicke in Ihren Release-Planungsprozess zu gewinnen. Weiterhin werde ich den zugrunde liegenden Metro-Plan unseres Release-Zugs aufzeigen, damit Sie sehen, wie Ihre Releases selbst in den komplexesten Szenarien einfacher planbar werden.

Developer Experience (DX) ist längst zu einem entscheidenden Erfolgsfaktor für API-Initiativen geworden. Ganz gleich, ob man APIs bereitstellt oder konsumiert: Reibungsverluste in der Entwicklung bremsen die Adoption, steigern den Supportaufwand und lassen im schlimmsten Fall Integrationen scheitern.

In diesem Vortrag erklären wir, was DX im Kontext von APIs eigentlich bedeutet und wie ihr als Plattform-Team sie sowohl für API-Provider als auch für -Consumer verbessern könnt.

Zielpublikum: Architekten, Entwickler, Platform Teams
Voraussetzungen:Grundlagenwissen zu APIs
Level: Practicing

Extended Abstract:
Themen wie API-Auffindbarkeit, konsistentes Design (z.B. mit Vacuum), Operations (z.B. mit Microcks) und der Lebenszyklus einer API (z.B. oasdiff) stehen dabei im Fokus. DX für APIs ist nicht "nice to have", sondern ein strategischer Hebel für Plattformwachstum und den Erfolg des Ökosystems.