Die korrekte Deploy-Sequenz im Detail und warum die Reihenfolge zählt

~8 Min. Lesezeit Zuletzt aktualisiert am 9. August 2026

Kapitel 5 hat die vierstufige Deploy-Sequenz bereits eingeführt. Nachdem wir mit der Team-Seite (Block 5) und den Praxis-Themen (Block 6) einige Male tatsächlich deployt haben, lohnt sich jetzt ein genauerer Blick darauf, warum jeder einzelne Schritt notwendig ist - nicht nur, dass er notwendig ist.

Die vier Schritte noch einmal, mit Begründung

# 1. CSS neu bauen
bin/npm --prefix app/design/frontend/Mironsoft/default/web/tailwind run build

# 2. Static Files löschen (WICHTIG: immer zuerst!)
cd src && rm -rf var/view_preprocessed/* pub/static/frontend/*

# 3. Static Content deployen
bin/magento setup:static-content:deploy de_DE -t Mironsoft/default -f

# 4. Cache leeren
bin/magento cache:flush

CSS bauen - erzeugt die aktuelle, minifizierte styles.css aus allen im Projekt verwendeten Tailwind-Klassen. Ohne diesen Schritt würde Schritt 3 eine veraltete CSS-Datei deployen.
Static Files löschen - Magento cached verarbeitete View-Dateien in var/view_preprocessed/ und ausgelieferte Assets in pub/static/frontend/. Bleiben alte Versionen dort liegen, kann setup:static-content:deploy unter Umständen aus dem Cache statt aus den frischen Quelldateien bedienen.
Static Content deployen - kopiert/kompiliert alle Frontend-Assets (CSS, Bilder, Templates-Vorverarbeitung) aus den Modul-/Theme-Quellverzeichnissen in pub/static/, wo sie tatsächlich ausgeliefert werden.
Cache leeren - Magentos interne Caches (Layout, Block-HTML, Konfiguration) können alte Referenzen auf jetzt veraltete Static-Content-Dateien enthalten und müssen deshalb zuletzt geleert werden.

Warum genau diese Reihenfolge - nicht eine andere

Würde man Schritt 2 (Löschen) nach Schritt 3 (Deploy) ausführen, würden die gerade frisch deployten Dateien direkt wieder mitgelöscht - das Ergebnis wäre eine Seite ganz ohne Styling. Würde man Schritt 2 komplett weglassen, deployed setup:static-content:deploy unter Umständen (abhängig vom internen Caching-Verhalten) nicht alle geänderten Dateien neu, weil einige noch als "aktuell" im Preprocessed-Cache markiert sind, obwohl sich der Quellcode geändert hat.

Achtung: Der "WICHTIG: immer zuerst"-Hinweis aus Schritt 2 ist keine Stilfrage, sondern ein häufiger, schwer zu debuggender Produktionsfehler: eine Seite, die nach einem Deployment augenscheinlich korrekt läuft, aber optisch veraltet aussieht - CSS-Änderungen fehlen, obwohl der Build augenscheinlich lief. Bei Verdacht auf dieses Problem: Schritte 2-4 erneut in korrekter Reihenfolge ausführen, nicht nur Schritt 1 wiederholen.

Entwicklungs-Workflow vs. volle Deploy-Sequenz

Während der lokalen Entwicklung mit aktivem Watcher (bin/start, siehe Kapitel 5) reicht in der Regel ein einfaches bin/cache-clean, um Änderungen zu sehen - der view_preprocessed-Cache spielt im Developer-Mode eine geringere Rolle. Die vollständige, vierstufige Sequenz mit produktivem Build ist vor allem für jedes Deployment auf eine Umgebung mit Production- oder Default-Mode zwingend.

Ein kleiner Deploy-Check nach jedem Deployment

Browser-Konsole öffnen (F12) - keine 404-Fehler für CSS/JS-Dateien?
Hart neu laden (Strg/Cmd + Shift + R), um Browser-Caching auszuschließen.
Eine kürzlich geänderte Tailwind-Klasse gezielt visuell prüfen.
Bei Hyvä-CSP-Themes: Konsole auf CSP-Verletzungsmeldungen prüfen (Kapitel 28).

Vorheriges Kapitel Von Luma auf Hyvä migrieren: typische Stolperfallen Nächstes Kapitel Typische Fehler und wie man sie debuggt (fehlendes registerInlineScript, CSP-Verletzungen, hartnäckige Caches)