Shopware Community UnConference 2024

Ein Jahr später, wieder in Köln

Am 23. und 24. März fand die Shopware Community UnConference statt, wieder in Köln, diesmal im Tor 28. Das Format ist unverändert: kein Programm vorab, Themen kommen von den Teilnehmern, abgestimmt wird mit Klebepunkten.

Beim zweiten Besuch nach einem Jahr wusste ich, worauf ich mich einlasse, und das verändert die Teilnahme. Beim ersten Mal überlegt man noch, ob das eigene Thema gut genug für eine Karte ist. Beim zweiten Mal weiß man, dass genau diese Frage der Grund ist, warum manche Themen nie diskutiert werden.

Auffällig war der Unterschied zum Vorjahr bei den Inhalten. 2023 hing die Wand voller KI-Fragen, teils grundsätzlicher Natur. Ein Jahr später ist der Ton nüchterner geworden, und der Schwerpunkt lag wieder stärker auf Handwerk: Testen, Betrieb, Werkzeuge.

Der Zustand vor der Sortierung: alle Vorschläge nebeneinander, jede Karte mit Abstimmungsfeldern für beide Tage.

Und das Ergebnis: der Sessionplan des ersten Tages, entstanden am Vormittag aus genau diesen Vorschlägen.

Der Plan liest sich wie ein Querschnitt durch die Sorgen des Jahres. Technisch standen Shopware-Cluster, HTTP-Caching, ein „Speedrun" durch Redis, Varnish und OpenSearch in unter 30 Minuten sowie Feedback zur damals frischen 6.6 auf der Liste. Daneben eine kritische Betrachtung von Composable Architecture und MACH, also ausgerechnet der Begriffe, mit denen die Branche zu dieser Zeit besonders gern warb.

Genauso aufschlussreich ist, was sonst noch dranhing: Barrierefreiheit mit Blick auf den European Accessibility Act 2025, Karriereentscheidungen in einer Welt nach KI, und eine Session mit dem Titel „Don't be a jerk" zu mentaler Gesundheit in der Technikbranche. Auf einer regulären Konferenz landen solche Themen selten im Hauptprogramm.

Testkonzepte, und warum es daran hakt

Eine der Sessions hatte den Titel „Let's build a test concept". Das trifft einen wunden Punkt in vielen Shopware-Projekten. Fast alle wissen, dass Tests sinnvoll sind. Deutlich weniger haben ein Konzept dafür, was überhaupt getestet werden soll.

Genau da liegt die Schwierigkeit. Ein Shop besteht aus zugekauften Erweiterungen, eigenem Code, Konfiguration und Daten. Alles zu testen ist unbezahlbar, nichts zu testen ist fahrlässig. Die eigentliche Arbeit besteht darin, die Stellen zu bestimmen, an denen ein Fehler richtig teuer wird: Preisberechnung, Steuerlogik, Checkout, Schnittstellen zu Warenwirtschaft und Zahlungsdienstleistern.

Eine Session dazu bringt genau das, was man allein schwer hinbekommt: Man hört, wo andere ihre Grenze gezogen haben und warum.

„Let's build a test concept", eine der Sessions am Samstag.

Ein Blick in echte Infrastruktur

Die zweite Session, die hängen geblieben ist, zeigte den Aufbau hinter einem großen Shopware-Betrieb: mehrere Anwendungsserver hinter Load Balancern, eine eigene Datenbankschicht mit Proxy davor, Suchcluster, mehrere Redis-Instanzen, Message Queues, dazu eine ganze Wand an Werkzeugen für Monitoring, Deployment und Backup.

Solche Folien sind aus zwei Gründen wertvoll. Erstens sieht man, dass der Sprung von „läuft auf einem Server" zu „läuft unter Last" kein Ausbau ist, sondern eine andere Architektur. Zweitens bekommt man ein Gefühl für die Größenordnung: Diese Ebene braucht Betriebswissen, das mit Shop-Entwicklung nur teilweise überlappt.

Für die eigene Arbeit heißt das vor allem, die Grenze zu kennen. Wer weiß, wie so ein Aufbau aussieht, kann einem Auftraggeber früher sagen, ab wann Hosting und Betrieb eigene Fachleute brauchen, statt es implizit mitzuversprechen. Für den laufenden Betrieb und die Wartung eines Shops ist genau diese Einschätzung der Anfang.

Infrastruktur hinter einem großen Shop, inklusive der Werkzeugkette drumherum.

Die Gegenrichtung war ebenfalls vertreten. In einer anderen Session ging es um die lokale Entwicklungsumgebung, aufgebaut aus Docker-Diensten mit einem Reverse Proxy davor. Zwischen diesen beiden Enden, dem Notebook und dem Produktivcluster, spielt sich der Alltag ab, und beide Seiten an einem Wochenende zu sehen, sortiert die eigene Einschätzung.

Das andere Ende: die lokale Umgebung als Docker-Konfiguration.

Am Sonntag entstand wie im Vorjahr ein komplett neuer Plan. Auf ihm standen unter anderem eine Runde zu Symfonys Assetmapper für die Storefront, offene Telemetrie mit Metriken und Tracing, Twig-Performance über statische Analyse, dazu eine Session über Wertschätzung im Team und eine PowerPoint-Karaoke-Runde.

Sonntag, neu geplant: von Assetmapper und Observability bis PowerPoint-Karaoke.

Warum ich wiederkomme

Die ehrlichste Begründung für eine zweite Teilnahme ist, dass die erste sich gelohnt hat. Es gibt keine Aufzeichnung, kein Skript und kein Zertifikat, aber es gibt zwei Tage mit Leuten, die dieselben Probleme haben und offen darüber reden.

Dazu kommt etwas, das man erst nach ein paar Jahren bemerkt: Man verfolgt die Themen der Branche über die Zeit. Was letztes Jahr eine offene Frage an der Pinnwand war, ist dieses Jahr entweder Alltag oder erledigt. Diese Entwicklung mitzubekommen ist schwer zu ersetzen, wenn man allein arbeitet.