Continuous Integration mit OXID
Bestandteil eines Releases ist auch die Aktivierung von neuen oder aktualisierten Modulen. Normalerweise erfolgt dies über die Modulkonfiguration im Shop-Admin. Bei einem automatisierten Deployment (CI/CD) muss dieser Schritt ebenfalls automatisiert werden. Dafür hatten wir den pcModuleActivator entwickelt. Neben dem Aktivieren von Modulen ist es auch möglich die Reihenfolge festzulegen, bestimmte Module inaktiv zu lassen sowie Views zu generieren. Je nach Situation kann es vorkommen dass das Deaktivieren der Module über das Shop-Framework nicht ausreicht, da weiterhin Einträge in der Datenbank vorhanden sind. Aus diesem Grund wird vor der Neuaktivierung die gesamte Modulkonfiguration, nicht Moduleinstellungen/Settings, aus der Datenbank gelöscht.
NEU: Die OXID Console
Der Nachfolger ist die Integration der gleichen/ähnlichen Logik in oxrun, dem Vorgänger der OXID Console. Diese wurde mit dem OXID eShop 6.2 veröffentlicht und basiert auf der Symfony Console Component. Neben bereits vorhandenen Befehlen wie z. B. Cache leeren oder einzelne Module aktivieren/deaktivieren besteht auch die Möglichkeit eigene Commands (oxideshop-component) zu integrieren.
Erweitertes OXID Modulhandling
Mit dem OXID Console Module Activator, einer Erweiterung des vorhandenen Befehls apply-configuration (siehe unten), stehen nun auch folgende Funktionen zur Verfügung:
- Zurücksetzen der Modulkonfiguration
- Installieren von definierten Module (install-configuration)
- Aktivieren von allen Modulen, ausgenommen Module auf der Blacklist
- Aktivieren von Modulen welche ausschließlich auf der Whitelist stehen
- Sortierung der Aktivierungsreihenfolge von Modulen
- Konfiguration für jeden Shop/Mandant einzeln möglich
Die OXID eShop Component kann über Packagist installiert werden oder/und ist unter folgendem Link zu finden:
https://github.com/proudcommerce/oxid-console-moduleactivator
Module in OXID 6.2
Das Modulhandling hat sich in OXID 6.2 grundlegend geändert. Bis dato wurden die Informationen zu Modulen (Status, Einstellungen, …) in der Datenbank (oxconfig) gespeichert. Neuerdings werden alle Informationen in YAML-Files gespeichert. Dabei hat jeder Shop/Mandant (EE) eine eigene Datei, z. B. /var/configuration/shops/1.yml. Im Backend (Shop-Admin) werden bereits alle modulspezifischen Informationen aus den YAML-Dateien gelesen. Im Frontend hingegen wird in der Übergangsphase noch die Datenbank genutzt.
Um eine vorhandene Modulkonfiguration zu aktiveren wird der Befehl vendor/bin/oe-console oe:module:apply-configuration verwendet. Nun werden die Module entsprechend ein- oder ausgeschalten, sowie die Moduleinstellungen/Settings in der Datenbank aktualisiert. Die Modulinstallation muss bereits im Vorfeld erfolgt sein, entweder automatisch über die Modulinstallation per composer oder manuell. Ggf. werden wir hierzu in Kürze noch einen ausführlichen Blogpost veröffentlichen. ;-)
