eurofunk Kappacher GmbH

Etablierte Firma

Alle Videos anzeigen

Effortless Versioning

Stefan Höller von eurofunk Kappacher zeigt in seinem devjobs.at TechTalk, wie das Unternehmen die Versionsverwaltung bei langen Produktzyklen mithilfe von Semantic Release gestaltet hat.

Beim Videoaufruf stimmst Du der Datenübermittlung an YouTube und der Datenschutzerklärung zu.

Video Zusammenfassung

In Effortless Versioning zeigt Stefan Höller, wie sein Team „God Components“ durch eine klar abgegrenzte Angular‑Komponentenbibliothek ersetzt, die in Figma entworfen, in Storybook dokumentiert und aus Resilienzgründen als Multi‑Repo geführt wird. Er erläutert eine Pipeline mit GitLab CI, Renovate und semantic‑release, in der das Angular‑Commitformat die semantische Versionierung, Tags, Changelogs und das automatische Publishing steuert; in der Live‑Demo behebt ein Fix fehlende globale Styles, löst ein Patch‑Release (2.4.2→2.4.3) aus und aktualisiert die konsumierende App. Die Zuschauer nehmen einen praxistauglichen Workflow mit, der „God Components“ vermeidet, stabile APIs fördert und inkrementelle, nachvollziehbare Releases ohne manuelles Versions-Feilschen ermöglicht.

Effortless Versioning in der Praxis: Wie Stefan Höller bei der eurofunk Kappacher GmbH Bibliotheks‑Releases mit Semantic Release, GitLab und Multi‑Repo bändigt

Kontext und Kernbotschaft der Session „Effortless Versioning“

In seiner Session „Effortless Versioning“ führt Stefan Höller von der eurofunk Kappacher GmbH durch eine sehr praktische Geschichte: Wie bringt man Ordnung in eine Frontend‑Welt mit langen Produktlebenszyklen, vielen beteiligten Entwicklerinnen und Entwicklern und einer wachsenden Anzahl gemeinsamer UI‑Bausteine – ohne am Ende im Chaos manueller Versionierung zu landen?

Wir bei DevJobs.at haben Höllers Weg besonders aufmerksam verfolgt: von der Problemdefinition (God‑Components im Monorepo) über Architekturentscheidungen (Multi‑Repo) und Teamrollen (Tech Leads, UX, Frontend) bis hin zu einer Pipeline, die mit GitLab, Renovate und vor allem Semantic Release den kompletten Weg von Commit‑Nachricht bis Paket‑Release automatisiert. Sein Fazit bringt es auf den Punkt: Mit klaren Konventionen und der richtigen Toolchain wird Versionierung tatsächlich „effortless“ – oder zumindest so nah dran, wie man es im realen Alltag bekommt.

„Ich muss nicht mehr über Versionierung nachdenken, was großartig ist. Ich kann einfach releasen.“

Das Problem: God‑Components im großen Monorepo

Die Ausgangslage:

Produktlebenszyklen von 15 Jahren oder länger
50+ Frontend‑Entwickler:innen
Ein großes Monorepo

Über Jahre gewachsene, wiederverwendete Bausteine – etwa Selects, Buttons oder Accordions – begannen sich zu „God‑Components“ zu entwickeln. Höller beschreibt diese Anti‑Pattern treffend als kleine Dinge, die „alles“ können. Ein Select, das gleichzeitig Combo‑Box, Suchfeld, Single‑ und Multi‑Select, Paginierung, Lazy Loading und Virtual Scrolling stemmen soll, wird mit jedem Feature fragiler.

Die Folge: mehr Bugs, mehr Fixes, mehr Seiteneffekte – eine immer wiederkehrende Schleife aus „Feature hinzufügen – etwas bricht – Fix – nächster Bruch“. Das war schwer zu warten, schwer zu testen und kulturprägend in die falsche Richtung: Jede Teamentscheidung, noch eine Sonderfunktion in ein zentrales UI‑Element zu packen, verschlimmerte den Zustand.

Der Gegenentwurf: Standardisierte Komponentenbibliothek mit klarer API

Die Lösung begann mit einer strategischen Designentscheidung: Weg vom „kann alles“‑Anspruch, hin zu standardisierten Komponenten mit klar definiertem Scope. Höller nennt die Ziele explizit:

Ein klar abgegrenzter Funktionsumfang
Eine verständliche, leicht konsumierbare API
Gute Dokumentation
Wiederverwendbarkeit über mehrere Produkte

Für die Umsetzung wählte das Team drei Rollen/Tools als Fundament:

Figma für Design und visuelle Spezifikation
Angular für die Implementierung
Storybook für Dokumentation und Showcase der Bibliothek

Diese Trias ist wichtig: Figma definiert das „Was“ (Look & Feel, Interaktion), Angular realisiert das „Wie“, und Storybook vermittelt das „Warum“ (Kontext, Beispiele, Zustände).

Monorepo oder Multi‑Repo? Warum die Wahl auf getrennte Repos fiel

Die nächste essenzielle Weichenstellung betraf die Frage: Wo lebt die Bibliothek?

Monorepo:
Vorteil: leicht zu integrieren, leicht zugänglich
Nachteil: ebenso leicht zu verändern – inklusive „kleiner“ Features, die niemand wirklich braucht, aber die Komplexität hochtreiben
Separates Repository (Multi‑Repo):
Vorteil: „resilient to change“ – Änderungen sind bewusster, geplante Artefakte; keine unmittelbare Kopplung an Produktcode
Nachteil: mehr Eigenaufwand beim Aufbau; Integration ist nicht „geschenkt“

Höllers Team wählte bewusst das Multi‑Repo. Der Zielsatz „Resilienz gegen Veränderung“ gab den Ausschlag. Die Bibliothek sollte damit eine eigene, kontrollierte Entwicklungseinheit werden – mit ihren eigenen Releases, Abhängigkeiten und Governance‑Mechanismen.

Verantwortlichkeiten: Tech Leads, UX und Frontend Hand in Hand

Wer treibt eine solche Bibliothek? Höller ordnet die Verantwortlichkeiten klar:

Tech Leads als technische Treiber:innen
UX‑Team für Designkompetenz und Erfahrung in Interaktionsgestaltung
Frontend‑Entwickler:innen für die Implementierung in Angular und das Tooling außenrum

Dadurch entstehen klare Schnittstellen: Strategie und technische Qualitätssicherung bei den Leads, „Design‑Quelle der Wahrheit“ im UX, und produktionsreife Umsetzung im Frontend.

Wartung ohne Heldentum: GitLab und Renovate

Die Instandhaltung stemmt das Team nicht mit händischen Pflegeaufgaben, sondern mit Automatisierung:

GitLab als Code‑Host und CI/CD‑Orchestrator (Pipelines für Qualität und Releases)
Renovate als „Dependency Radar“, der automatisch Pull Requests für veraltete Abhängigkeiten anlegt

Renovate reduziert dabei eine typische „alle paar Monate“‑Pflichtaufgabe („Welche Dependencies sind eigentlich veraltet?“) auf das Prüfen und Mergen von automatisch erstellten PRs. Häufig reicht tatsächlich „merge“, manchmal sind kleine Anpassungen nötig. Der wichtige Punkt: Kein Mensch muss daran denken; das System erzeugt den Aktualisierungsimpuls.

Publizieren in die Paket‑Registry: bitte nicht manuell

Die Bibliothek sollte in der Paket‑Registry verfügbar sein – aber nicht durch eine Gatekeeper‑Rolle, die händisch Versionen anstößt. Das Ziel war eine Entscheidung über Release‑Zeitpunkte und ‑Nummern, die aus dem Entwicklungsfluss heraus entsteht.

Hier kommt der zentrale Baustein ins Spiel, der Höllers „Effortless Versioning“ praktisch möglich macht: Semantic Release.

Semantic Release: Commit‑getriebene Versionierung und Release‑Automation

Semantic Release ist eine Node.js‑basierte Komponente, die in Projekte verschiedenster Art integriert werden kann. Die Idee ist bestechend:

Auswertung aller Commits seit dem letzten Release
Ableitung, welches Version‑Level zu erhöhen ist (Patch, Minor, Major)
Erzeugen des Versions‑Tags
Publizieren in die Registry
Erstellen eines Changelogs – ebenfalls aus den Commit‑Nachrichten heraus

Die Voraussetzung dafür: Commit‑Nachrichten in einem standardisierten Format. Höller verweist auf das „Angular Commit Message Format“. Dessen Kernelemente:

Ein Typ (z. B. fix, feat, refactor, build)
Ein Scope (z. B. button, accordion, select)
Eine kurze Zusammenfassung
Optionaler Body für Details – inklusive der Markierung von breaking changes

Damit wird Versionierung semantisch hergeleitet anstatt manuell verhandelt. Höller formuliert eine der spürbaren Folgen so:

„Ich kann mir keine beliebigen Versionsnummern mehr ausdenken. Das wird durch die Änderungen diktiert, die ich mache.“

Semantic Versioning richtig lesen

Die Mechanik basiert auf SemVer mit seinen drei Ziffern:

Patch: Bugfixes und kleine Änderungen
Minor: neue Features, die abwärtskompatibel sind
Major: Breaking Changes – nicht zu verwechseln mit „kompletter Produkt‑Relaunch“; entscheidend ist die Auswirkung auf die API und damit auf Konsument:innen der Bibliothek

Höller verdeutlicht die Übersetzung von Commit‑Typen in Versionserhöhungen anhand von Beispielen:

Ein Fix („fix …“) erhöht die Patch‑Version
Ein neues Feature („feat …“) erhöht die Minor‑Version
Änderungen mit API‑Bruch werden im Commit‑Body als Breaking Change deklariert und führen zu Major
Eine Refactor‑Änderung sollte normalerweise keinen Effekt haben; depreziert sie allerdings eine alte API (z. B. ein Mixin), ist das eine veröffentlichungsrelevante Änderung – hier eine Minor‑Erhöhung, weil kein Bruch

Diese Klarheit in der Bedeutung erlaubt zwei Dinge: Sie informiert Konsument:innen verlässlich, und sie entkoppelt den Moment der Implementierung vom Moment der Veröffentlichung – die Pipeline kümmert sich darum.

Die Demo: Ein fehlendes Style‑Asset wird zum End‑to‑End‑Release

Der Praxisteil in Höllers Vortrag zeigt die Funktionsweise in einer kompakten, aber sehr typischen Situation: Eine Beispiel‑App (Counter) nutzt Komponenten aus der Bibliothek. Optisch passt etwas nicht: Globale Styles aus der Bibliothek kommen in der App nicht an.

Die Spur führt zur Bibliothek: Styles sind zwar definiert (Farben, Gradient usw.) und werden über ein Barrel‑File exportiert – aber die package.json exportiert die Assets nicht. Höller behebt genau das: Die Styles werden als Asset exportiert.

Dann folgt der für „Effortless Versioning“ entscheidende Schritt: die Commit‑Nachricht. Er klassifiziert die Änderung als Bugfix und beschreibt sie sinngemäß als „globale Styles als Assets hinzufügen“. Direktes Pushen auf main triggert im GitLab‑Projekt die Pipeline:

Dependencies installieren
Bibliothek bauen
Veröffentlichung vorbereiten

Wichtiges Detail: Der Build‑Job legt die generierten Artefakte als Pipeline‑Artefakt ab – die Veröffentlichungsstufe nutzt genau dieses Artefakt wieder. In der Release‑Stage läuft Semantic Release.

Der Blick in die Pipeline‑Logs zeigt die konsequente Auswertung:

Vorheriges Tag: 2.4.2
Seitdem: ein Fix‑Commit
Schlussfolgerung: Patch‑Erhöhung auf 2.4.3
Veröffentlichung des Pakets in der Registry
Erstellung von Release‑Notes aus dem Commit

Die Registry bestätigt das neue Paket („effortless lib 2.4.3“), inklusive Release‑Eintrag.

Auf Konsumentenseite aktualisiert die Beispiel‑App die Bibliotheksversion. Anschließend importiert die App die Styles und führt das bereitgestellte Mixin aus. Das Ergebnis ist unmittelbar sichtbar: Gradient und Buttons entsprechen nun der Design‑Spezifikation aus der Bibliothek.

Dieser Durchstich – von einer kleinen Korrektur im Paket über Commit‑Analyse, Tagging, Release‑Artefakt bis zur aktualisierten App – ist die beste Illustration für den „effortless“‑Ansatz. Keine händische Versionsverhandlung, keine manuellen Changelogs, keine Sonderschritte – die Standardisierung der Commit‑Nachricht reicht, damit die Pipeline ihren Job tut.

Lehren aus der Praxis: Disziplin am Commit, Entlastung im Alltag

Höller benennt offen, was das Setup kostet und was es anschließend spart:

Setup‑Reibung ist real: „Deployment ist schwer“, so sein augenzwinkernder Kommentar zu „50 Commits Schmerz“ während des Demo‑Aufsetzens.
Versionsnummern sind kein Diskussionsgegenstand mehr: „Ich kann nicht mit jemandem verhandeln, das wird diktiert.“
Commit‑Nachrichten sind bewusst zu schreiben: Typ, Scope, Summary – plus klare Deklaration von Breaking Changes im Body.
Die Pipeline korrigiert gnadenlos: Fehlerhafte Commit‑Formate fallen auf. Höller empfiehlt Commit‑Message‑Linting ausdrücklich.
Nach dem Setup ist wenig Pflege nötig: Semantic Release „funktioniert sehr oft einfach“ – und hilft nebenbei, Breaking Changes zu vermeiden.
Inkrementelles Updaten statt Mammut‑Releases: Kleine Schritte lassen sich schneller konsumieren, Fehler lassen sich leichter isolieren und beheben.

„Ich kann mein Projekt Schritt für Schritt aktualisieren, nicht diese großen Versionsupdates, die ewig dauern. So entdecke und isoliere ich Bugs einfacher.“

Das Ergebnis inhaltlicher Natur: Die Komponentenbibliothek steht heute ohne God‑Components da, mit soliden APIs, klar definiertem Verhalten und Storybook‑Dokumentation. Das Design ist von dedizierten Designer:innen getrieben – eine klare Trennung von Zuständigkeiten.

Pipeline‑Bausteine im Überblick: Was wirklich zählt

Aus unserer Perspektive kristallisieren sich die minimalen Bausteine heraus, die für Effortless Versioning nötig sind:

Klare Architekturgrenze für die Bibliothek

Separates Repository für Resilienz
Eigene Release‑Kadenz und ‑Governance

Strenges Commit‑Format

Typen wie fix, feat, refactor, build
Scope pro betroffenem Modul/Komponententyp
Aussagekräftige Summary
Body für Details und explizite Kennzeichnung von Breaking Changes

CI‑Pipeline, die Build‑Artefakte weiterreicht

Install‑Job
Build‑Job mit Artefaktbereitstellung
Release‑Job, der genau dieses Artefakt verwendet und Semantic Release ausführt

Automatisches Dependency‑Management

Renovate für kontinuierliche Aktualisierungsvorschläge

Paket‑Registry als Distributionskanal

Versionen und Changelogs für Konsument:innen sichtbar

Wichtige semantische Details

„Major“ bedeutet API‑Bruch – nicht „großes Re‑Write“. Das ist wichtig für die Erwartungshaltung in Teams und gegenüber Stakeholdern.
Deprecations sind veröffentlichungsrelevant – auch ohne Bruch. Eine Refactor‑Änderung, die etwas depreziert, verdient eine Minor‑Erhöhung.
Das Konsument:innen‑Erlebnis zählt: Eine sauber gepflegte Registry mit Changelogs und SemVer‑Korrektheit schafft Vertrauen.

Konsumieren der Bibliothek: kleine Updates, klare Signale

Auf der „anderen Seite“ dieser Pipeline sitzt die Anwendung, die die Bibliothek konsumiert. Höllers Demo zeigt den idealen Flow aus Konsumentensicht:

Das Update ist minimalinvasiv (Patch‑Erhöhung)
Die App aktualisiert die Version
Die App importiert die bereitgestellten Styles korrekt
Das Ergebnis ist visuell überprüfbar und erfüllt die Designrichtlinien

Die darin liegende Tugend ist nicht zu unterschätzen: Teams trauen sich, kleinere Updates mitzunehmen, wenn die semantische Bedeutung eindeutig und das Risiko kontrolliert ist. Das schafft die Grundlage für kontinuierliche Verbesserung statt seltener, riskanter „Big Bang“‑Upgrades.

Warum Semantic Release hier so gut passt

Semantic Release trifft Höllers Ziele an mehreren Stellen:

Automatisierung ersetzt manuelle Entscheidungen über Versionen
Verbindlichkeit der Commit‑Sprache ersetzt Bauchgefühl
Änderungen sind nachvollziehbar (Changelogs), Release‑Prozesse wiederholbar
Die Brücke zwischen Implementierung (Commit) und Veröffentlichung (Tag/Registry) ist stabil

Bemerkenswert ist zudem der Integrationshorizont: Obwohl Semantic Release Node‑basiert ist, verweist Höller auf breite Unterstützung über npm hinaus – etwa Docker Hub sowie Ökosysteme wie Rust, Python, Java (Maven) oder Erweiterungen für Firefox, Chrome oder VS Code. Für Teams, die über mehrere Tech‑Stacks hinweg arbeiten, ist das ein starkes Argument für ein einheitliches Release‑Prinzip.

Praktische Empfehlungen, direkt aus der Session ableitbar

Aus dem Vortrag lassen sich unmittelbar umsetzbare Schritte ableiten:

Setzt die Commit‑Konvention durch – inklusive Linting. Ohne konsistente Commit‑Nachrichten kann Semantic Release seine Stärke nicht ausspielen.
Trennt die Bibliothek organisatorisch vom Produktcode. Das bremst „Feature‑Einschläge“ und zwingt zu sauberem API‑Design.
Legt die Release‑Pipeline so an, dass Build‑Artefakte exakt in der Release‑Stufe wiederverwendet werden. Keine doppelten Builds, keine abweichenden Artefakte.
Nutzt Renovate früh. Ein stetiger Strom kleiner Dependency‑Updates ist weniger riskant als sporadische Groß‑Upgrades.
Definiert, wie Deprecations kommuniziert werden. In Commit‑Bodies, Changelogs und Storybook – Konsument:innen brauchen Orientierung.
Versteht „Major“ richtig. Es ist ein Signal über API‑Veränderungen – nicht zwingend über Umfang oder Aufwand.

Häufige Stolpersteine – und wie man sie vermeidet

„Schnelle Sonderfälle“ in der Bibliothek: Genau dafür wurde Multi‑Repo gewählt. Jede Änderung erfordert Absicht und Planung.
Unklare Verantwortlichkeiten: Tech Leads, UX und Frontend mit klaren Rollen – das ist nicht Bürokratie, sondern Qualitätsmanagement.
Manuelle Release‑Schritte: Menschen sind schlecht in wiederholbaren, kleinteiligen Prozessen. Maschinen sind gut darin.
Fehlende Sichtbarkeit von Änderungen: Ohne Changelogs müssen Konsument:innen raten. Mit Semantic Release entstehen diese Artefakte automatisch.

Zitate, die hängen bleiben

„Major ist nicht ein kompletter Relaunch. Es geht um Breaking Changes, also API‑Brüche.“

„Renovate erstellt Pull Requests, und oft drücke ich nur auf Merge.“

„Die Pipeline sagt mir, wenn ich falsch liege – besonders mit Commit‑Message‑Linting.“

Diese knappen Sätze kondensieren die Kultur, die Höller skizziert: bewusstes Arbeiten am Commit, viel Automatisierung, wenig Ego beim Versionieren.

Fazit: Effortless Versioning ist eine Teamleistung – und eine Frage der Standards

„Effortless Versioning“ ist keine Magie. Es ist das Resultat von sauber gezogenen Grenzen (separates Repo), von klaren Rollen (Tech Leads, UX, Frontend), und von Tools, die Standards erzwingen statt Aufwände zu erzeugen (GitLab‑CI, Renovate, Semantic Release).

Die Demo – ein fehlendes Style‑Asset, ein präziser Fix‑Commit, eine saubere Pipeline, ein Patch‑Release, ein sichtbarer Effekt in der App – zeigt, dass der Weg vom Commit zur echten Wertlieferung kurz sein kann. Für Teams mit langen Produktzyklen und vielen Beteiligten ist das nicht nur „nett“, sondern essenziell.

Wer aus „Effortless Versioning“ von Stefan Höller bei der eurofunk Kappacher GmbH nur einen Gedanken mitnimmt, nimmt am besten diesen: Standardisiere den kleinsten Baustein deiner Arbeit (den Commit), dann kann der Rest (Version, Tag, Release, Changelog) automatisiert zuverlässig entstehen. Genau darin liegt die Entlastung – und am Ende die Qualität.

Weiterführende Hinweise (aus der Session genannt)

Semantische Versionierung (Spezifikation)
Semantic Release (Projektseite)
Angular Commit Message Format
Anleitung zur GitLab‑Registry und deren Integration

Weitere Tech Talks

Weitere Tech Lead Stories

Weitere Dev Stories