LTSC
mono­repo

Overview

Für eine Schweizer Versicherungs­gesellschaft haben wir eine Microservice-Applikation mit verteilter Repository-Struktur in ein Monorepo überführt. Dadurch wurden Changes an der zentralen Domain-Model-Library einfacher, schneller und verlässlicher lieferbar.

Kunde Schweizer Versicherungs­gesellschaft
Bereich Developer Tooling, Monorepo, CI/CD
Anwendung 8 Microservices & Domain-Model-Library

Ausgangslage

Lange Change-Durchlaufzeit

Der hohe Change-Overhead führte zu langen Change-Durchlaufzeiten und bremste die Entwicklung stark aus.

Deployment-Risiken

Es bestand ein hohes Risiko, Services mit untereinander inkompatiblen Domain-Model-Library-Versionen zu deployen, was zu schwierig nachvollziehbaren Fehlern führte.

Viele Repositories

8 Microservices und eine zentrale Domain-Model-Library lagen in getrennten Repositories, was zu Overhead beim Entwickeln führte.

Abhängige Pull Requests

Ein Domain-Model-Change konnte bis zu 9 abhängige Repository-übergreifende Pull Requests erfordern, was die Koordination von Merges und Deployments stark erschwerte. Dieser Umstand wurde durch den hohen Grad an paralleler Entwicklung zusätzlich erschwert.

Workarounds im Code

Der organisatorische Overhead begünstigte technische Umgehungslösungen, die zu dupliziertem oder schwer wartbarem Code führten.

Unser Beitrag

  • Analyse der bestehenden Repository-, Build- und Deployment-Struktur.
  • Lösungsdesign und Erprobung des Monorepo-Ansatzes in einem Proof of Concept.
  • Zusammenführung mehrerer Git-Repositories unter Beibehaltung der Commit-Historie.
  • Optimierung des IDE-Setups.
  • Engineering der Continuous Integration mit GitHub Actions.
  • Erweiterung der Continuous Delivery um Monorepo-Support.
  • Unterstützung des Entwicklerteams bei der Migration (IDE, ungemergte Branches).

Lösung

Wir haben Repository-Struktur, lokales Setup und Delivery-Pipeline so zusammengeführt, dass fachliche Änderungen wieder als zusammenhängende Arbeitseinheit geliefert werden können.

Monorepo-Struktur

Microservices und Domain-Model-Library liegen in einem gemeinsamen Repository mit klarer Ordnerstruktur.

Ein Workspace

Entwickler arbeiten lokal in einem konsistenten IDE-Setup statt in 9 Workspaces.

GitHub Actions

Die CI-Pipeline buildet nur, was gebuildet werden muss, und ist auf kurze Durchlaufzeiten optimiert.

Gemeinsamer Review

Fachliche Änderungen werden als ein zusammenhängender Pull Request reviewt.

Resultate

Reduzierter Change-Overhead

Änderungen an der Business-Logik können in einem einzelnen Pull Request reviewt und gemerged werden.

Höhere Velocity

Das Team liefert bei gleicher Teamgrösse schneller und mit weniger Koordinationsaufwand.

Bessere Developer Experience

Ein lokaler Workspace vereinfacht Navigation, Refactoring, Testing und fachliche Änderungen. mvn install fällt weg.

Stabileres Delivery

CI/CD ist Monorepo-aware und reduziert Versions- und Deployment-bedingte Fehler.

Hohe Entwicklerzufriedenheit

Die vereinfachte Arbeit im Alltag erhöhte die Entwicklerzufriedenheit spürbar.

Adoption im Unternehmen

Der Monorepo-Ansatz wurde von weiteren Teams in der Organisation übernommen.

Technologien

  • GitHub Actions
  • Apache Maven
  • Quarkus
  • Angular
  • IntelliJ IDEA
  • Argo CD