Deployment-Sequenz für ein so großes Modul

Die Deploy-Sequenz aus CLAUDE.md - CSS bauen, view_preprocessed/pub/static löschen, Static Content deployen, Cache leeren - reicht für ein normales Frontend-Update. Mironsoft_Loyalty bringt zwölf Data Patches, einen neuen Cache-Typ, eine eigene Crongroup, einen neuen Configuration Type und Admin-Knockout-Komponenten mit - genug zusätzliche bewegliche Teile, um die Standard-Sequenz um drei vorgelagerte und einen nachgelagerten Schritt zu erweitern.

Die erweiterte Sequenz

# 1. Wartungsmodus (bei einer derart umfangreichen Schema-Änderung empfehlenswert)
bin/magento maintenance:enable

# 2. Datenbank-Schema und Data Patches anwenden
bin/magento setup:upgrade

# 3. DI-Compile - PFLICHT wegen neuer Preferences, virtualTypes und Configuration Type
bin/magento setup:di:compile

# 4. CSS neu bauen (neue Templates aus Block 6/7/8/9)
bin/npm --prefix app/design/frontend/Mironsoft/default/web/tailwind run build

# 5. Static Files löschen (WICHTIG: immer zuerst, vor dem Deploy)
cd src && rm -rf var/view_preprocessed/* pub/static/frontend/* pub/static/adminhtml/*

# 6. Static Content deployen (Storefront UND Admin - Block 7 bringt Admin-JS mit)
bin/magento setup:static-content:deploy de_DE en_US -t Mironsoft/default -f
bin/magento setup:static-content:deploy de_DE en_US --area adminhtml -f

# 7. Cache vollständig leeren (schließt den eigenen Typ mironsoft_loyalty_catalog ein)
bin/magento cache:flush

# 8. Cronjob-Aktivierung prüfen
bin/magento cron:run
bin/mysql -e "SELECT job_code, status, scheduled_at FROM cron_schedule WHERE job_code = 'mironsoft_loyalty_expire_points' ORDER BY schedule_id DESC LIMIT 5;"

# 9. Wartungsmodus wieder ausschalten
bin/magento maintenance:disable

Schritt 2: die zwölf Data Patches in Abhängigkeitsreihenfolge

setup:upgrade führt Data Patches nicht in Datei- oder Kapitel-Reihenfolge aus, sondern in der von getDependencies() berechneten topologischen Reihenfolge. Über die ganze Serie hinweg sind zwölf Patches entstanden - hier ihr tatsächlicher Ausführungsgraph:

Ausführungsgraph aller zwölf Data Patches (Wurzeln parallel, Kinder erst nach ihrem Elternteil)

InstallRewardEntityType                          (Kapitel 11, keine Abhängigkeit)
  `-- InstallRewardAttributes                    (Kapitel 13)

InstallProductLoyaltyAttribute                   (Kapitel 19, keine Abhängigkeit)
  `-- UpdateProductLoyaltyAttributeScope          (Kapitel 25)

InstallCategoryLoyaltyAttribute                  (Kapitel 20, keine Abhängigkeit)

InstallCustomerLoyaltyAttributes                 (Kapitel 21, keine Abhängigkeit)
  `-- UpdateCustomerLoyaltyTierBackend            (Kapitel 26)

InstallSalesLoyaltyAttributes                    (Kapitel 23, keine Abhängigkeit)
  |-- InstallSalesLoyaltyRedeemedAttribute        (Kapitel 63)
  `-- InstallSalesLoyaltyPointsPackageCreditedAttribute (Kapitel 76)

InstallPointsPackageAttributeSet                 (Kapitel 74, keine Abhängigkeit)
  `-- InstallPointsPackageAmountAttribute         (Kapitel 74)

Tipp: Sechs der zwölf Patches haben gar keine Abhängigkeit und könnten in beliebiger Reihenfolge zuerst laufen - Magento garantiert nur die partielle Ordnung, die getDependencies() tatsächlich verlangt, keine vollständige, deterministische Gesamtreihenfolge über alle zwölf hinweg.

Schritt 3: warum setup:di:compile hier nicht optional ist

Im Developer-Modus funktioniert vieles auch ohne expliziten Compile-Lauf, weil Magento fehlende, generierte Klassen bei Bedarf automatisch nachgeneriert. Für dieses Modul gilt das nicht durchgehend: Der neue Configuration Type (LoyaltyFeatureFlagsConfigType, Kapitel 88) trägt sich als zusätzlicher Eintrag in das types-Argument-Array von Magento\Framework\App\Config ein - ein Array-Merge in di.xml, der laut der projekteigenen Erfahrung (feedback_di_xml_compile_gotcha) auch im Developer-Modus kommentarlos ignoriert werden kann, wenn kein Compile-Lauf stattfindet, und im Zweifel zweimal laufen sollte.

bin/magento setup:di:compile
# bei hartnäckigen Fällen (Konfigurationstyp erscheint nicht):
bin/magento setup:di:compile

Achtung: Auf einem Produktivsystem im production-Modus ist setup:di:compile ohnehin zwingend - dort generiert Magento keine fehlenden Klassen automatisch nach. Ein vergessener Compile-Lauf zeigt sich dort nicht als leise ignorierte Einstellung, sondern als harter 500er.

Schritt 6: warum beide Bereiche deployen

Block 7 bringt Knockout-Admin-Komponenten für die Page-Builder-Vorschau (Kapitel 60) mit, Block 8 eine Knockout-Zahlungsart-Komponente im Storefront-Checkout (Kapitel 65) - beide liegen jeweils unter view/adminhtml/web/ bzw. view/frontend/web/ und müssen deshalb beide Bereiche im setup:static-content:deploy-Lauf abdecken, nicht nur den Storefront wie bei einem reinen Theme-Update.

Schritt 8: Cron-Aktivierung verifizieren

Die eigene Crongroup mironsoft_loyalty (Kapitel 32) wird nicht durch einen eigenen Installationsbefehl aktiv, sondern automatisch, sobald der config-Cache (durch cache:flush in Schritt 7 ohnehin geleert) die crontab.xml neu einliest und Magentos generischer ProcessCronQueueObserver beim nächsten regulälater Cron-Lauf neue Einträge für jede aktive Gruppe generiert. bin/magento cron:run stößt diesen Generierungslauf sofort an, statt auf den nächsten System-Cron-Tick zu warten - praktisch für eine unmittelbare Verifikation nach dem Deploy.

Mit erfolgreich abgeschlossenem Deployment ist die reine Funktionsfähigkeit sichergestellt - Kapitel 100 geht der Frage nach, wie sich das Modul unter Last verhält.