Deployment-Hygiene: Wie du Staging-Live-Drift bei Shopware vermeidest

Die kurze Antwort

Staging-Live-Drift entsteht fast immer auf dieselbe Weise: Jemand behebt unter Zeitdruck ein Problem direkt auf dem Live-Server, statt den Fix zuerst über Staging und die Codebasis laufen zu lassen. Danach unterscheidet sich der Live-Stand vom Repository, und der nächste reguläre Deploy überschreibt den Notfall-Fix wieder, unbemerkt. Abhilfe schafft ein Deployment-Prozess, der Direktedits auf Live technisch unattraktiv macht: eine echte Staging-Umgebung, ein automatisiertes CI/CD-Setup und Tools wie der Shopware Deployment Helper, die Updates konsistent auf beide Umgebungen anwenden.

Ob das in deinem Shop schon passiert ist, kannst du in wenigen Minuten selbst prüfen: Schau in die Git-Historie. Unser Shopware-Team sieht bei übernommenen Projekten immer wieder Commits mit der Nachricht „Live-Stand“ und rund 1.000 Änderungen auf einmal. Das heißt, es wurde direkt auf Live entwickelt und erst nachträglich ins Repository übernommen, also genau andersherum. In manchen Projekten gibt es weder ein Repository noch ein Staging-System.

Was ist eine Staging-Umgebung bzw. ein Staging-System bei Shopware?

Eine Staging-Umgebung ist eine separate Kopie des Shops, auf der Änderungen getestet werden, bevor sie live gehen: mit eigener Domain, eigener Datenbank und eigenem Server- oder Container-Setup, aber möglichst identischer Konfiguration zur Produktivumgebung. Shopware bringt dafür laut der offiziellen Staging-Dokumentation einen eigenen Konsolenbefehl mit, der ein System explizit als Staging markiert.

Ohne diese Markierung verhält sich ein Testsystem technisch wie ein zweiter Live-Shop, inklusive des Risikos, aus Versehen echte Kunden-E-Mails zu verschicken.

Was ist der Unterschied zwischen Staging und Live?

Der zentrale Unterschied liegt im Zweck: Live bedient echte Kunden und echte Bestellungen, Staging existiert ausschließlich zum Testen. Damit dieser Unterschied auch technisch abgesichert ist, aktiviert der Befehl system:setup:staging laut offizieller Staging-Dokumentation einen eigenen Modus, der unter anderem den Versand von E-Mails deaktiviert und Apps mit aktiven Verbindungen zu externen Diensten entfernt.

Diese Sicherung ist wichtig, weil eine Staging-Umgebung meist aus einer Kopie der Live-Datenbank entsteht, inklusive aller hinterlegten Zahlungs- und Versanddienst-Anbindungen.

In unserer Projektpraxis hat sich eine feste Reihenfolge bewährt. Entwickelt wird lokal, in einer Umgebung, die dem Server-Setup so nah wie möglich kommt. Danach geht die Änderung auf Staging, wo der Kunde mitschaut und das Ergebnis fachlich gegen das Ticket abnimmt. Erst dann folgt Live. Die Begründung aus unserem Shopware-Team ist schlicht: „Wenn du dich auf Live vertust, steht der Shop.“

Was ist eine Staging-Instanz, und wie unterscheidet sie sich vom Testsystem?

In der Praxis werden beide Begriffe oft synonym verwendet. Der feine Unterschied: Eine Staging-Instanz bildet die Produktivumgebung möglichst exakt nach, meist direkt aus einem Deployment desselben Git-Repositorys, während ein „Testsystem“ auch eine lockerere Entwicklungsumgebung ohne diesen Anspruch meinen kann. Die offizielle Staging-Dokumentation empfiehlt, Staging konsequent aus dem Repository heraus zu deployen, statt Dateien manuell zu kopieren, damit der Code-Stand exakt dem von Live entspricht.

Je näher Staging an Live liegt, desto aussagekräftiger sind die dort durchgeführten Tests.

Wie richtet man ein Shopware-Testsystem/Staging-System ein?

Der empfohlene Weg ist ein zweiter Deploy desselben Git-Repositorys auf eine eigene Domain, gefolgt von einer eigenen, idealerweise anonymisierten Kopie der Datenbank und eigenen .env-Zugangsdaten. Danach aktiviert der Konsolenbefehl system:setup:staging auf der neuen Instanz den Staging-Modus, der den E-Mail-Versand an Kunden blockiert und riskante externe App-Verbindungen kappt.

Ein Punkt, der dabei häufig übersehen wird: Live und Staging sollten keine gemeinsamen Ressourcen wie MySQL, Redis oder OpenSearch nutzen. Die offizielle Staging-Dokumentation warnt ausdrücklich, dass geteilte Ressourcen zu Datenkorruption und Performance-Problemen führen können.

Wie viele Plugin-Lizenzen braucht man für Staging- und Testsysteme?

Das hängt vom gebuchten Shopware-Plan ab. Laut Shopware-Account-FAQ zu Staging-Environments kann bei den kostenpflichtigen Plänen Rise, Evolve und Beyond eine Staging-Domain vom Shopware-Account-Team offiziell als Staging markiert werden. Sie übernimmt dann automatisch alle Erweiterungs-Lizenzen der Hauptdomain, mit einer je nach Plan gestaffelten Anzahl erlaubter Staging-Domains (Rise 2, Evolve 4, Beyond unbegrenzt).

Für Community- und Professional-Edition-Shops gilt diese automatische Übernahme nicht: Ein Plugin, das dort auf einer separaten Staging-Domain läuft, braucht grundsätzlich eine eigene Lizenz.

Was ist der CI/CD-Prozess im E-Commerce-Kontext?

CI/CD steht für Continuous Integration/Continuous Deployment: Code-Änderungen werden automatisiert getestet, gebaut und ausgerollt, statt jeden Schritt manuell auszuführen. Bei Shopware trennt sich das laut Shopware-CLI-Dokumentation offiziell in zwei Phasen: eine Build-Phase, in der die Shopware CLI Abhängigkeiten installiert und das Theme kompiliert, und eine Deploy-Phase, in der der Deployment Helper das fertige Artefakt auf dem Zielsystem einspielt.

Diese Trennung sorgt dafür, dass der eigentliche Deploy-Schritt auf dem Server schnell bleibt, weil dort nichts mehr neu kompiliert werden muss.

Wie automatisiert man Shopware-Deployments (Deployer, GitLab CI, GitHub Actions)?

Die offizielle Deployer-Dokumentation beschreibt Deployer als einen Weg, den Build- und Deploy-Prozess über eine PHP-basierte Deployment-Konfiguration zu automatisieren. Ebenso gängig ist es, dieselben CLI- und Deployment-Helper-Befehle innerhalb einer GitLab-CI- oder GitHub-Actions-Pipeline auszuführen, statt sie manuell auf der Kommandozeile zu starten.

Für welches der drei Systeme du dich entscheidest, hängt vor allem davon ab, wo euer Code bereits liegt. Wichtig ist, dass derselbe automatisierte Ablauf für Staging und Live gilt, damit beide Umgebungen aus derselben Quelle entstehen.

Braucht ein Shopware-Deployment einen Wartungsmodus?

Nein, ein gut aufgesetzter Deployment-Prozess kommt ohne Wartungsmodus aus. Muss der Shop bei jedem Deployment eine halbe Stunde auf eine Wartungsseite umschalten, kann in dieser Zeit niemand kaufen, und bei häufigen Releases summiert sich das. Weil der Build schon vor dem Deploy abgeschlossen ist, lässt sich das fertige Artefakt im laufenden Betrieb einspielen, ohne dass Besucher etwas davon merken.

So laufen Deployments auch bei unseren Kunden: im laufenden Betrieb, ohne Wartungsseite. Für Shopbetreiber ist das der eigentliche Nutzen einer sauberen CI/CD-Pipeline. Releases kosten keine Verkaufszeit mehr und können deshalb häufiger und in kleineren Schritten erfolgen.

Welche Deployment-Fehler treten bei Shopware-Updates typischerweise auf?

Die häufigste Fehlerquelle ist, einzelne Schritte eines Updates von Hand statt über ein einheitliches Tool auszuführen, etwa Composer-Update, Datenbank-Migration und Cache-Neuaufbau in der falschen Reihenfolge oder mit vergessenen Zwischenschritten. Der Shopware Deployment Helper wurde genau deshalb entwickelt: um diese Schritte zu vereinheitlichen und dieselbe Prozedur für Neuinstallationen wie für Updates automatisch anzuwenden.

Ein Update, das auf Staging manuell fehlerfrei lief, kann auf Live trotzdem scheitern, wenn dort ein anderer, ebenfalls manueller Ablauf verwendet wurde.

Wie verhindert man Live-Server-Direktedits und Code-Drift zwischen Umgebungen?

Der wirksamste Hebel liegt im Prozess selbst: Wenn der reguläre Deployment-Weg schneller und zuverlässiger ist als ein manueller SSH-Fix, verschwindet der Anreiz für Direktedits von selbst. Ein standardisierter Deployment Helper, der Environment-Drift durch einheitliche Abläufe zwischen Staging und Live reduziert, ist dafür die technische Grundlage.

Ergänzend hilft eine einfache Regel: Jede Änderung geht zuerst ins Repository, danach automatisiert auf Staging und erst danach auf Live. Eine Ausnahme gibt es. Lässt sich ein akuter Fehler weder lokal noch auf Staging reproduzieren, ist ein Fix direkt auf Live im echten Notfall vertretbar. Die Änderung wird dann sofort auf Staging und ins Repository nachgezogen. Unser Shopware-Team arbeitet dabei nach dem Grundsatz: „Stage ist immer mindestens auf dem Code-Stand wie Produktiv.“ Staging darf Live vorauslaufen, aber nie hinterherhinken.

Dieser Notfall ist in der Praxis selten. Auch bei kritischen Fehlern bleibt fast immer Zeit für den regulären Weg über Staging, denn auf die Viertelstunde kommt es in der Regel nicht an.

Wie flexibel sollte ein Release-Prozess sein?

Flexibel genug, dass ein einzelnes fehlerhaftes Ticket nicht das ganze Release aufhält. In vielen Setups geht ein kompletter Develop- oder Sprint-Branch als festes Paket live. Steckt in einem Ticket darin noch ein Fehler, blockiert das das gesamte Deployment. Besser ist ein Prozess, in dem sich jedes Ticket einzeln live nehmen und ein problematisches Ticket kurzfristig aus dem Release herausnehmen lässt.

So arbeiten wir bei datrycs. Ein typischer Fall aus unserer Praxis: Der Kunde bemerkt fünf Minuten vor dem geplanten Deployment noch einen Fehler in einem Ticket. Das Ticket wird in wenigen Minuten herausgenommen, alle anderen Änderungen gehen trotzdem wie geplant live. Das nimmt auch den Druck, fragwürdige Änderungen noch schnell mitzunehmen, nur weil sonst das ganze Paket wartet.

Wie funktioniert der Shopware Deployment Helper bzw. die Shopware CLI dabei?

Die Shopware CLI übernimmt die Build-Phase: Sie installiert Abhängigkeiten und kompiliert das Theme zu einem fertigen Deployment-Artefakt. Der Deployment Helper übernimmt anschließend die Deploy-Phase auf dem Zielsystem: Er erkennt automatisch, ob es sich um eine Neuinstallation oder ein Update handelt, verwaltet Erweiterungen und führt Datenbank-Migrationen aus, ohne dass Assets dort erneut gebaut werden müssen.

Dieselbe Kombination aus CLI-Build und Deployment-Helper-Deploy lässt sich unverändert für Staging und Live einsetzen.

Wie synchronisiert man Datenbank und Dateien zwischen Staging und Live, ohne DSGVO-Vorgaben zu verletzen?

Ein 1:1-Kopieren der Live-Datenbank auf Staging bedeutet, dass echte Kundendaten auf einem System landen, das oft weniger streng abgesichert ist. Die Shopware CLI bietet laut offizieller Staging-Dokumentation einen eigenen Befehl, der einen Datenbank-Dump mit anonymisierten Daten erzeugt, sodass die Struktur erhalten bleibt, personenbezogene Inhalte aber entfernt werden.

Bei Dateien sind Produktbilder meist unkritisch. Vorsicht gilt vor allem bei hochgeladenen Kundendokumenten wie Rechnungsanhängen, die nicht ungeprüft auf Staging landen sollten.

Neben dem Datenschutz zählt der Zeitaufwand. In einem sauberen Setup unterscheidet sich das Testsystem in der Regel nur beim Datenstand von Live. Damit Tests aussagekräftig bleiben, muss sich der aktuelle Live-Datenstand mit Produkten und Konfiguration mit vertretbarem Aufwand auf Staging spiegeln lassen. Manuell kostet das nach unserer Erfahrung schnell einen halben Tag, automatisiert über einen anonymisierten Dump geht es deutlich schneller.

Welche Fehler zeigen sich typischerweise erst nach einem Live-Deploy?

Manche Fehler treten erst unter echter Last oder mit echten Daten auf: ein nicht neu aufgebauter HTTP-Cache, ein Theme, das für Live in einer anderen PHP- oder Node-Version gebaut wurde als für Staging, weil beide nicht aus demselben Build-Artefakt stammen, oder API-Anbindungen zu Zahlungs- und Versanddienstleistern mit anderen Live- als Staging-Zugangsdaten. Ein sauber getrenntes Staging-System mit identischer Konfiguration deckt genau diese Fälle vor dem eigentlichen Go-live auf.

Wer diese Unterschiede kennt, richtet Staging von vornherein so ein, dass genau diese kritischen Punkte mitgetestet werden, statt sie erst live zu entdecken. Genau hier schließt eine saubere Post-Launch-Wartung an: Deployment-Hygiene gehört zur laufenden Betriebsroutine, genauso wie die laufende Optimierung der Shop-Performance.

Wie wir dich unterstützen können

Wir bei datrycs richten Deployment-Pipelines so ein, dass Staging und Live aus derselben automatisierten Quelle entstehen, inklusive Deployment Helper, CI/CD-Anbindung, einzeln deploybarer Tickets, Releases ohne Wartungsmodus und DSGVO-konformer Staging-Daten. Was ein Stage-System an laufenden Kosten mitbringt, hängt vom Hosting-Setup ab. Bei spezialisierten Managed-Hostern ist es oft schon im Paket enthalten, wie unser Hosting-Vergleich zeigt. Die Gesamtkosten eines Shopware-Projekts stehen in unserem Kostenartikel. Wenn dein Team noch manuell auf dem Live-Server nachbessert, sprich uns über das Kontaktformular am Ende dieser Seite an.