Shopware-Entwicklung 2026: Was in echten Projekten funktioniert - und was nur theoretisch gut klingt

Kurz gesagt: Der Unterschied zwischen einem Shopware-Projekt, das entspannt läuft, und einem, das jeden Release-Tag zum Risiko macht, liegt selten im Code - sondern in der Pipeline drumherum. Meine Erfahrung aus Projekten: Docker als lokale Basis, shopware-cli für Build und Projektaufgaben, ein Deployment über den Deployment Helper statt FTP, und eine Staging-Umgebung, die den Namen verdient. Nichts davon ist Raketentechnik - aber die Kombination entscheidet.

Das eigentliche Problem: Fragmentierung

Frag zehn Shopware-Entwickler nach ihrem lokalen Setup und du bekommst acht verschiedene Antworten: natives PHP mit Valet, Symfony CLI, Devenv, Dockware, selbstgebaute Docker-Composes, MAMP-Erben. Jedes funktioniert irgendwie - und genau das ist das Problem: In Teams und bei Übergaben kostet jede Sonderlösung Zeit. Der neue Kollege kämpft zwei Tage mit der Umgebung statt mit dem Ticket, und „works on my machine" ist Alltag statt Ausnahme.

Shopware selbst arbeitet sichtbar daran, hier einen goldenen Weg zu etablieren - die Richtung ist klar: Docker als Standard, eine CLI als zentrales Werkzeug. Meine Empfehlung: Geh diesen Weg mit, statt eine weitere Insellösung zu pflegen.

Lokal: Docker, konsequent

Was sich in meinen Projekten bewährt hat:

• Docker als einzige Voraussetzung. Kein lokal installiertes PHP mit Extension-Puzzle, keine Versionskonflikte zwischen Projekten. Die PHP-Version des Projekts steht im Container, nicht auf dem Rechner.
• Dieselben Services wie live: MySQL/MariaDB in der Live-Version, bei Bedarf Redis, OpenSearch/Elasticsearch und Mailpit für ausgehende Mails. Wer lokal ohne Suchserver entwickelt und live einen betreibt, testet an der Realität vorbei.
• Reproduzierbarkeit vor Komfort: Die Umgebung liegt versioniert im Repository. Jeder im Team - und jeder KI-Agent, der zunehmend mitarbeitet - kann sie mit einem Befehl hochziehen.

Build: shopware-cli statt Skript-Sammlung

Die shopware-cli hat sich als das zentrale Werkzeug etabliert - für Extension-Builds, Projekt-Builds (shopware-cli project ci) und Store-Uploads. Der Punkt, der in Projekten am meisten bringt: Der Build läuft identisch lokal und in der CI. Composer-Install, Asset-Kompilierung, alles ein Befehl. Damit sterben die undokumentierten „build.sh"-Skripte, die nur auf dem Rechner des ursprünglichen Entwicklers funktionieren.

Dazu gehört eine CI-Pipeline (GitHub Actions oder GitLab), die bei jedem Push mindestens baut, statische Analyse (PHPStan) und Tests ausführt. Nicht als Dogma - als Frühwarnsystem.

Deployment: der Deployment Helper ist der Standard

Das Deployment-Anti-Pattern schlechthin sehe ich immer noch regelmäßig: Änderungen per SFTP direkt auf den Live-Server, undokumentiert, an Git vorbei. Das funktioniert genau bis zum ersten Update - dann weiß niemand mehr, was auf dem Server eigentlich läuft.

Der Shopware Deployment Helper ist die richtige Antwort: ein Einstiegspunkt, der Installation prüft, Migrationen ausführt, Extensions verwaltet und Theme-Kompilierung anstößt - idempotent und wiederholbar. Kombiniert mit dem Transportweg deiner Wahl (Deployer, rsync, Container) ergibt das ein Deployment, das jeder im Team auslösen kann, ohne den „einen Kollegen, der weiß, wie es geht".

Die Regeln, die ich in jedem Projekt durchsetze:

1. Kein Weg am Git vorbei. Was nicht im Repository ist, existiert nicht.
2. Staging ist Pflicht, nicht Luxus. Ein Update, das nie auf Staging lief, läuft auch nicht auf Produktion - es wurde nur noch nicht bemerkt.
3. Deployments sind langweilig. Wenn ein Deployment Nervenkitzel erzeugt, ist der Prozess kaputt, nicht der Tag.

Was nur theoretisch gut klingt

Der Vollständigkeit halber - Dinge, die ich in Projekten wieder abbaue:

• Kubernetes für den 50.000-€-Umsatz-Shop. Die Betriebskomplexität frisst jeden theoretischen Vorteil. Ein sauberes Docker-Setup auf einem ordentlichen Server reicht weit.
• Microservices um Shopware herum, wo ein Plugin oder eine schlanke Symfony-Anwendung reicht. Verteilte Systeme sind kein Selbstzweck.
• Eigene Deployment-Frameworks. Jede Agentur, die ihr eigenes Deployment-Tool pflegt, bezahlt es mit jedem Projekt erneut. Die Standard-Werkzeuge sind gut genug geworden - nutzt sie.

Fazit

2026 gibt es keinen guten Grund mehr für exotische Shopware-Setups: Docker lokal, shopware-cli für Builds, Deployment Helper für den Weg auf den Server, Staging als Sicherheitsnetz. Das ist kein großes Projekt - die Umstellung eines bestehenden Setups ist meist in wenigen Tagen erledigt und amortisiert sich mit jedem Update. Die teuerste Pipeline ist die, die nur in einem Kopf existiert.