OXID eShop SDK: Unsere Devs teilen ihr Tool mit euch
OXID eShop SDK: Unsere Devs teilen ihr Tool mit euch
Wir sind immer wieder stolz auf unser großes Entwicklernetzwerk aus Partnern, Agenturen, Freelancern und mehr. Doch was könnte ein solches Netzwerk noch weiter unterstützen? Eine gemeinsame Basis zu Entwicklungszwecken! Und diese Idee kommt gar nicht von uns, sondern von euch. Ihr habt gefragt, wie unser Development Team intern arbeitet. Als Support Account Manager habe ich, Steven, damit vielleicht erstmal weniger zutun, aber im Hinblick auf meine OXID Academy Tätigkeiten war ich dann doch ziemlich neugierig und bin mit eurer Frage zu meinen Kollegen gegangen. Nun sind Devs ja oftmals keine Freunde großer Worte. Also dachten sie sich:
Das OXID eShop Docker SDK zusammen mit dessen Recipes ist also auf GitHub frei zugänglich und kann von euch zur Entwicklung von OXID eShop Projekten und Erweiterungen ausprobiert werden. Ich sage an dieser Stelle schon mal:
Ein tolles Hilfsmittel, um die Entwicklungsphase einfacher und effizienter zu gestalten.
Aber etwas mehr Informationen wollte ich den Kollegen aus der Entwicklung dann doch entlocken. Also bin ich an Dr. Heike Reuter herangetreten und habe mal genauer nachgefragt…
Heike, was sind denn Gründe für ein SDK?
Nun ja, das OXID eShop SDK ist die Antwort auf die Frage: Wie komme ich von null auf zum laufenden Entwicklungsshop? Früher wurden hierzu meist recht umständlich virtuelle Maschinen mit VMware, VirtualBox und Co. aufgesetzt. Diese Zeiten sind zum Glück vorbei. Ganz besonders Docker hat hier einen neuen Weg geebnet, auf den auch wir uns schnell begeben haben. Einmal ein SDK mit Recipes zusammengebaut und schon kann jeder Entwickler simpel und schnell seine lokale Entwicklungsumgebung aufsetzen. Hinzu gesellt sich der Vorteil eines einheitlichen Setups für alle Nutzer des SDKs.
Und was steckt da nun alles drin?
Mit einer Shop-Installation alleine ist es nicht (immer) getan. So müssen beispielsweise Tests in der lokalen Umgebung laufen. Unsere Acceptance Tests verwenden Codeception. Das benötigt dann einen Selenium Service. Außerdem will man vielleicht auch sehen, was der lokale Shop so an E-Mails versendet. Also braucht man idealerweise etwas wie MailHog. Ein einfacher Zugang zur Datenbank mit einem Tool wie Adminer ist auch immer nützlich.
Man erkennt also deutlich, dass es viel mehr gibt als nur die Shop-Instanz. Je mehr man will oder braucht, desto umfangreicher wird die Einrichtung. Wir setzen deshalb auf Docker Container. Via Docker werden beispielsweise ein MySQL Container inklusive Adminer zur Verfügung gestellt oder auch eine fertige Konfiguration, um direkt mit dem Debugger eine Analyse des Codes durchzuführen. Was sonst noch enthalten ist, findet ihr in der README im GitHub Repository des SDKs.
Gibt es das Ganze nur für OXID eShop 7?
Für den ganz schnellen Weg zum lokalen Shop haben wir sogenannte Recipes gebaut. Diese sorgen dafür, dass alle wichtigen Komponenten für den OXID eShop vorhanden sind. Außerdem erlauben verschiedene Rezepte unterschiedliche Konfigurationen bereitzustellen. Das war uns sehr wichtig, um nicht ausschließlich die aktuelle OXID eShop Maintenance Version zu unterstützen, sondern auch die Legacy oder gar ältere Versionen. Es ist also problemlos möglich, mit der gewünschten Version zu arbeiten.
Wie verwendet man das SDK jetzt eigentlich?
Zweimal git clone, das passende Rezept auswählen und ein Shell Script starten. Danach kurz ein Kaffee holen und wenn man wieder am Rechner ist, #läuft der OXID eShop in der lokalen Umgebung. So einfach ist es! Die Befehle sehen folgendermaßen aus:
echo customProjectName && git clone https://github.com/OXID-eSales/docker-eshop-sdk.git $_ && cd $_
git clone https://github.com/OXID-eSales/docker-eshop-sdk-recipes recipes/oxid-esales
./recipes/oxid-esales/shop/b-7.0.x-ce-twig.sh
Diese Commands klonen zuerst das SDK und anschließend die Recipes. Dann wird das gewünschte Rezept ausgewählt, das Script gestartet und schon #läuft alles automatisch.
Prima! Magst du uns sonst noch etwas dazu sagen?
Wie wäre es noch mit etwas Geschichte zum Schluss? Keine Angst, das wird keine lange Geschichtsstunde - Ich möchte nur kurz den Hergang des SDKs mitteilen. Eigentlich handelte es sich um ein Privatprojekt eines unserer Entwickler, der gerne schnell eine frische Entwicklungsumgebung herbeizaubern wollte. Also stellte er seine Lösung dem Team vor und es wurde beschlossen: Wir wollen das, wir brauchen das und gemeinsam machen wir es noch besser!
Dieses Gemeinsam wollen wir auch mit euch ausleben, weshalb wir uns entschieden haben, unser Tool mit euch zu teilen. Schließlich ist es eben kein Produkt oder kostenpflichtiges Add-On für den Shop, sondern erleichtert einfach unsere und von jetzt an vielleicht auch eure Arbeit. Letztendlich sind ja auch wir daran interessiert, dass ihr tolle Projekte und Module umsetzt.