Wer auf Production dasselbe baut wie auf Staging, testet in Wirklichkeit nicht das, was er auf Staging getestet hat. Die Promotion eines validierten Artefakts – statt eines Neu-Builds – ist das Fundament reproduzierbarer Deployments. GitLab Environments, manuelle Freigaben und korrekte Variable-Scopes machen diesen Prozess teamfähig und auditierbar.
Ein Deployment-Prozess ohne Checkliste ist ein Prozess, der bei jeder Ausführung leicht anders abläuft. Für Magento-Teams mit GitLab CI/CD gibt es eine klare Reihenfolge — von Repository-Regeln und CI-Variablen über Build-Artefakte und Release-Struktur bis zu Verify-Jobs und dokumentiertem Rollback.
Static Content Deployment auf dem Produktionsserver auszuführen bedeutet: lange Wartungsfenster, serverabhängige Build-Ergebnisse und unkontrollierbare Laufzeiten. Der richtige Platz für SCD ist der CI-Build-Job – mit Hyvä Tailwind-Build, setup:di:compile und pub/static als kontrollierbares Artefakt, das auf jeden Server deployt werden kann.
Ein Symlink-Rollback reicht nicht immer. Wenn Datenbankmigrationen Teil des Deployments sind, muss ein aktuelles DB-Backup existieren – bevor der erste Migrationschritt ausgeführt wird, nicht danach.
Zero-Downtime wird versprochen und selten klar definiert. Dieser Artikel erklärt ehrlich, wo der Symlink-Switch wirklich ohne Ausfallzeit funktioniert – und wo Datenbankmigrationen unvermeidlich ein kurzes Wartungsfenster erfordern.
Welche Variablen müssen gesetzt werden? Wie sind Jobs korrekt strukturiert? In welcher Reihenfolge werden Magento-Kommandos ausgeführt? Dieses Cheatsheet beantwortet diese Fragen kompakt und vollständig – als Nachschlagewerk für den Deployment-Alltag.
Der atomare Symlink-Wechsel ist der technische Kern von Zero-Downtime-Deployments für Magento. Statt Dateien direkt zu überschreiben – was Inkonsistenz erzeugt – wird das neue Release vollständig vorbereitet und dann in einem einzigen Kernel-Systemcall als current aktiviert. Rollback ist damit kein Notfallplan, sondern eine Millisekunden-Operation.
Nach einem Deployment ist der Full-Page-Cache leer. Die ersten echten Besucher erleben Ladezeiten, die nichts mit der eigentlichen Shopperformance zu tun haben. Ein automatisierter Warmup-Job in GitLab CI füllt den Cache mit den wichtigsten Seiten, bevor der erste Mensch die Startseite öffnet.
Ein Magento-Rollback ist mehr als ein Symlink-Wechsel. Datenbank, Queue-Nachrichten, Static Content und Elasticsearch-Indizes folgen eigenen Regeln. Wer nur Dateien zurückrollt, riskiert Inkonsistenzen, die schwieriger zu beheben sind als das ursprüngliche Problem.
GitLab Review Apps ermöglichen Preview-Umgebungen für jeden Feature-Branch. Klingt verlockend — aber Magento ist kein einfaches Node.js-Projekt. Datenbank, Media, Redis, Elasticsearch und ein komplexer Build-Prozess machen Review Apps zu einem ernsthaften Infrastrukturprojekt.