Produktionsmodus und Deploys für Hyvä-Shops

Hyvä macht das Frontend leichter, ändert aber nichts an den Grundlagen eines gut betriebenen Magento-Shops. Ein Shop im falschen Modus oder ein Deploy von Hand bleibt langsam und fehleranfällig, egal mit welchem Theme.

Dieser Beitrag zeigt, wie wir Hyvä-Shops betreiben und deployen, von der Modus-Einstellung bis zu den Prüfungen nach einem Release.

Immer im Produktionsmodus

Magento hat drei Modi: default, developer und production. Live-Shops gehören in den Produktionsmodus.

bin/magento deploy:mode:set production

Im Produktionsmodus liefert Magento vorab erzeugte statische Dateien und kompilierten Code aus, statt sie bei jeder Anfrage zu generieren. Fehler werden protokolliert statt Besuchern angezeigt.

Der Developer-Modus ist nur für die lokale Arbeit gedacht. Wir finden regelmäßig Live-Shops, die noch im Default- oder Developer-Modus laufen – und das zu ändern ist eine der günstigsten Performance-Optimierungen überhaupt.

Der Produktionsmodus gehört auch zum Setup hinter unserem Hyvä-vs-Luma-Benchmark. Ein fairer Vergleich setzt voraus, dass beide Themes so laufen, wie ein echter Shop laufen sollte.

Der Tailwind-Build gehört zum Deploy

Hyvä-Styles werden mit Tailwind CSS gebaut. Der Build durchsucht Ihre Templates und erzeugt ein Stylesheet, das nur die Klassen enthält, die Sie tatsächlich verwenden.

Das CSS muss daher bei jeder Änderung an Templates oder Theme-Konfiguration neu gebaut werden, bevor die statischen Inhalte deployt werden:

cd app/design/frontend/Vendor/hyva-child/web/tailwind
npm ci
npm run build

In unseren Shops werden die Tailwind-Design-Tokens während des Deploys aus Konfigurations- und Theme-Dateien neu erzeugt. So landen Header- und Markenfarben, die unter Stores > Configuration gesetzt wurden, im Stylesheet, ohne dass jemand Code bearbeitet.

Details zu den Tokens und zur Build-Pipeline finden Sie in Tailwind in Hyvä: Design-Tokens und die Build-Pipeline.

Ein wiederholbarer Deploy-Ablauf

Jeder Deploy sollte dieselben Schritte in derselben Reihenfolge ausführen. Wir haben sie in ein Skript gegossen, damit sich niemand daran erinnern muss.

1. Release abrufen und Abhängigkeiten mit Composer installieren.
2. Tailwind CSS für jedes Hyvä-Theme bauen.
3. Wartungsmodus aktivieren, wenn das Release Datenbankänderungen enthält.
4. Führen Sie bin/magento setup:upgrade.
5. Führen Sie bin/magento setup:di:compile.
6. Statische Inhalte für jedes verwendete Gebietsschema deployen.
7. Magento-Cache leeren und PHP-FPM neu laden, damit OPcache den neuen Code übernimmt.
8. Wartungsmodus deaktivieren.
9. CDN leeren und die wichtigsten Seiten aufwärmen.

bin/magento setup:upgrade --keep-generated
bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f en_GB de_DE
bin/magento cache:flush

Wer außerhalb des Live-Verzeichnisses baut und erst am Ende umschaltet, hält die Ausfallzeit kurz. Releases in separaten Ordnern mit Symlink-Umschaltung ermöglichen zudem ein schnelles Rollback.

Indexer, Cron und Hintergrundaufgaben

Produktive Shops sollten Indexer im Schedule-Modus betreiben, nicht „Update on Save“. Das Speichern eines Produkts sollte einen Admin-Nutzer nicht warten lassen, während der ganze Katalog neu indexiert wird.

bin/magento indexer:set-mode schedule

Die geplante Indexierung hängt vom Magento-Cron ab, Cron muss also zuverlässig laufen. Ein hängender Cron zeigt sich daran, dass Preise, Bestände oder neue Produkte nicht im Frontend erscheinen.

Auch andere Jobs gehören in den Cron. In unserem Hyvä-Demo-Shop erstellt Cron jede Nacht WebP-Kopien der Produktbilder und räumt Testbestellungen auf.

Der Server darunter

Der Produktionsmodus funktioniert am besten auf einem Server, der für Magento gebaut ist. Der Stack, den wir für Hyvä-Shops betreiben, sieht so aus:

Separate PHP-FPM-Pools sorgen dafür, dass ein stark ausgelasteter Shop einem anderen auf demselben Server keine Ressourcen wegnimmt. Mehr zur Wahl des Hostings finden Sie unter beste Magento-Hosting.

Updates und Sicherheitspatches

Magento veröffentlicht regelmäßig Sicherheitspatches und neue Versionen, und Hyvä bringt eigene Updates heraus. Beides sollte denselben Deploy-Prozess durchlaufen wie jede andere Änderung.

• Aktualisieren Sie zuerst eine Staging-Kopie. Führen Sie dort den vollständigen Deploy aus und testen Sie den Checkout, bevor Sie den Live-Shop anfassen.
• Aktualisieren Sie Extensions zusammen mit Magento. Ein Modul, das nicht für die neue Version bereit ist, kann Frontend oder Admin lahmlegen.
• Halten Sie das Child-Theme klein. Je weniger Parent-Templates Sie überschreiben, desto weniger Arbeit bringt jedes Hyvä-Update.
• Halten Sie alles in der Versionskontrolle. Composer-Dateien, das Child-Theme und das Deploy-Skript gehören alle ins Repository.

Vor einem größeren Upgrade empfiehlt sich ein Extension-Audit – es zeigt, welche Module zuerst Aufmerksamkeit brauchen.

Prüfungen nach jedem Release

Ein Deploy ist nicht abgeschlossen, wenn das Skript endet. Wir arbeiten auf der Live-URL eine kurze Checkliste ab:

• Startseite, eine Kategorie- und eine Produktseite laden in jeder Store View.
• „In den Warenkorb“ funktioniert und der Mini-Warenkorb aktualisiert sich.
• Der Checkout erreicht mit jeder Zahlungsart den Zahlungsschritt.
• Keine Fehler in der Browser-Konsole oder in den Magento-Logs.
• Ein Lighthouse-Lauf auf der echten URL hinter dem CDN, nachdem der Cache aufgewärmt ist.

Hyvä Checkout hat eigene Content-Security-Policy-Regeln. Ein neues Zahlungsskript oder Tracking-Tag kann dort blockiert werden, daher verdient der Checkout nach jedem Release, das ihn betrifft, einen echten Test.

Stolpersteine, auf die wir gestoßen sind

• Veralteter Cache nach einer Layout-Änderung. Wenn eine Änderung nicht sichtbar wird, prüfen Sie jede Cache-Ebene, bevor Sie den Code debuggen.
• Ein fehlendes Gebietsschema im Static Deploy. Eine Sprache lädt dann ohne Styles oder Skripte.
• Den Tailwind-Build vergessen. Neue Klassen in einem Template wirken erst, wenn das CSS neu gebaut ist.
• Den Origin testen. Wir testen die öffentliche URL hinter dem CDN mit einem normalen Browser-User-Agent, weil unser nginx Bot-User-Agents blockiert.

FAQ

Braucht Hyvä einen anderen Deploy-Prozess als Luma?

Im Wesentlichen denselben. Hinzu kommt vor allem der Tailwind-CSS-Build, der vor dem Deploy der statischen Inhalte laufen muss, wann immer sich Templates oder Styles ändern.

Kann ich Templates direkt auf dem Live-Server bearbeiten?

Davon raten wir ab. Im Produktionsmodus brauchen Template- und Style-Änderungen einen Build und Deploy, und von Hand gemachte Änderungen gehen beim nächsten Release verloren.

Woran erkenne ich, ob mein Shop im Produktionsmodus läuft?

Führen Sie bin/magento deploy:mode:show auf dem Server. Steht dort nicht production, sollten Sie das als Erstes beheben.

Optimierte Server mit skriptbasierten Deploys, Updates und Sicherheit für Hyvä-Shops gehören zu unserem Hyvä-Service. Für Performance-Arbeit an einem bestehenden Shop siehe Magento-Performance-Optimierung.