Blog Einträge

shoptimax und Pixelboxx gemeinsam mit OXID eSales auf der dmexco 2017

Perfekt verschmolzene Digital-Experten-DNA!

Die Digital Asset Management-Experten der Pixelboxx GmbH und die Experten des Nürnberger E-Commerce-Lösungsanbieters shoptimax GmbH präsentieren sich am 13. & 14. September als Mitaussteller am Stand (C 058 – Halle 7) der OXID eSales AG auf der dmexco 2017. Im Mittelpunkt der Präsentation steht das Produkt smxIRIS, ein neuartiges Realtime Image Publishing System zur Onlineshop- und Webauftritt-Optimierung.

In Zeiten immer höherer Ansprüche an die schnellstmögliche Abrufbarkeit von Onlineshops und Webauftritten, sind Online-Dienstleister stetig darum bemüht, für ihre Kunden effektive und profitable Optimierungsmöglichkeiten zu entwickeln. Am besten gelingt dies durch gezielten Know-how- und Wissenstransfer, wie es bei shoptimax und Pixelboxx seit Mai dieses Jahres der Fall ist.

shoptimax und Pixelboxx vereinen ihre Experten-DNA

shoptimax und Pixelboxx präsentieren sich 2017 mit „vereinter Experten-DNA“ am Stand C 058 – Halle 7 der OXID eSales AG. Seit Beginn der Partnerschaft im Mai arbeiten die beiden Unternehmen gemeinsam daran, die Pflege, Ausgabe und den Abruf von Bildern für Anbieter und Konsumenten im Web effizienter, kostengünstiger und komfortabler zu gestalten. Mit im Gepäck haben die Unternehmen ein innovatives Produkt, das die Kernkompetenzen des E-Commerce Spezialisten shoptimax und des Digital Asset Management-Experten Pixelboxx auf neuartige Weise miteinander vereint: smxIRIS.

smxIRIS – Visual Content schnell, sicher und responsive veröffentlichen

Betreiber von Onlineshops und Webauftritten, die zahlreiche (Produkt-)Bilder im Einsatz haben, profitieren mit smxIRIS auf vielfältige Weise: das innovative Realtime Image Publishing System ermöglicht eine schnelle und variantenreiche Bearbeitung sowie den optimalen und schnellen Einsatz sämtlicher Bilder auf jedem Endgerät.

Auf Basis einmalig auf einem externen Server hinterlegter Masterbilder, wird automatisch die optimale Auflösung und Größe für jede Bildschirmgröße berechnet. Die Auslieferung an verschiedene Einsatzstellen in Shops oder anderen Internetseiten erfolgt schließlich „on-the-fly“. smxIRIS bietet außerdem die Möglichkeit zur regelbasierte Transformation mit einer Vielzahl von Bild-, Text- und Wasserzeichenoperationen in Echtzeitverarbeitung an (u.a. 360-Grad-Ansichten aus Bilderserien, interaktive Zoomfunktionen oder freigestellte Varianten des Ursprungsbilds). Sämtliche Arbeitsschritte werden vom System automatisch durchgeführt und per URL-Parametrierung an den Shop bzw. Webauftritt übergeben.

Treffen Sie shoptimax und Pixelboxx auf der dmexco 2017

Tickets für die dmexco sind ab dem 17. Juli 2017 bereits für 99 Euro hier verfügbar. Merken Sie sich also schon jetzt den 13. & 14. September 2017 vor und vereinbaren Sie im Vorfeld einen Termin mit uns!
Schreiben Sie uns einfach an info@shoptimax.de oder rufen Sie uns unter der Telefonnummer +49 (0) 911 255 66 10 an. Wir freuen uns schon jetzt darauf, Sie persönlich kennen zu lernen.

Im Vorfeld – kostenloses Webinar!

Sollten wir bereits jetzt Ihr Interesse an Realtime Image Publishing geweckt haben, können Sie sich in einem kostenlosen Webinar einen eigenen Eindruck von der Effizienz und Leistungsstärke des Produkts smxIRIS verschaffen. Anhand eines OXID-Demo-Shop-Systems erläutern Ihnen die Experten von shoptimax und Pixelboxx live die Vorteile und zeigen konkrete Anwendungsfälle. Es wird unter anderem darauf eingegangen, wie Quellbilder on-the-fly skaliert, freigestellt, gelabelt oder mit einem Wasserzeichen versehen werden können und sämtliche Änderungen in Echtzeit und ohne Performanceverluste an ihren Bestimmungsort ausgeliefert werden.

Das Webinar findet statt am:

18. Juli 2017 um 11.00 Uhr

Sie können sich hier für das kostenlose Webinar anmelden.

Ausführliche Informationen zu smxIRIS erhalten Sie außerdem auf der smxIRIS-Produkt-Webseite.

Zierfisch oder Wal – lokale Software-Entwicklung mit Docker

Pünktlich zum 4. Geburtstag von Docker möchte ich ein kleines Fazit ziehen, ob und wie sich Docker-Container für die lokale Entwicklung im Agentur-Alltag mit sehr heterogenen Entwicklungs-Systemen (Windows Home / Pro, von 7 bis 10, Mac OS, Linux) der einzelnen Mitarbeiter bewähren können, welche Vorteile, aber auch Schwachstellen und Probleme es ggf. bei der täglichen Arbeit gibt und ob es sich lohnt, auf den blauen Wal zu setzen.

Die Anfänge

Vor knapp zwei Jahren fing ich an, mich erstmals mit Docker auseinanderzusetzen. Damals wie heute ging es dabei zentral darum, mit möglichst wenig Aufwand eine einheitliche, einfach aufzusetzende lokale Entwicklungsumgebung für verschiedene Software-Projekte zu haben, die idealerweise systemunabhängig zur Verfügung stehen sollte.

Lösungen mit MAMP, XAMP, LAMP usw. waren kaum beherrschbar, die Versionen der einzelnen Komponenten (Webserver, Datenbank, PHP-Umgebung, etc.) auf den Systemen der Mitarbeiter wucherten vor sich hin, unterschiedlichste Projekte stellten auch unterschiedlichste Anforderungen (ZendGuard Loader, ioncube Loader, Opcode-Caches, diverse PHP-Versionen, NodeJS, etc. etc.). Oder es wurde gar gemeinsam gleichzeitig auf nur einem Test-System entwickelt, die Mitarbeiter überschrieben sich „fröhlich“ gegenseitig ihre Änderungen. Gab es irgendwo einen Fehler im Code mussten alle warten, bis der Schuldige das Problem behoben hatte und das System wieder lief… kurzum: totale Anarchie :)

Für jedes Projekt aber eigene VMs zu „basteln“ war ebenso zeitaufwändig wie hardware-hungrig… was also tun? Docker schien eine gute Lösung zu sein, mit Docker Toolbox war es auch für Windows und Mac OS verfügbar, es gab vorgefertigte Docker-Images für Apache, PHP, Mysql auf Docker Hub usw.

Allerdings war Docker Compose noch im Entstehen, grafische Tools zur Container-Administration waren Mangelware, einzelne Container wurden also auf der Kommandozeile über „docker run …“ gestartet. Für „richtige“ Entwickler natürlich ok, für Template- und Frontend-Kollegen eher „so naja“ … ;)
Der Einstieg war also eher holprig, erste Container waren der einfacheren Administration halber „all-in-one“, also entgegen der Docker-Prinzipien liefen Apache, mehrere PHP-Versionen über „phpbrew“, Mysql, NodeJs usw. in einem gemeinsamen Container und waren damit eigentlich schon fast ein „VM-Ersatz“.

Weiterlesen

Continuous Delivery Teil 2 – Ansible Tipps

Im ersten Teil dieser Blogserie haben wir den allgemeinen Entwicklungsworkflow bei shoptimax beleuchtet – in diesem Teil soll es um konkrete Tipps zum Deployment mit Ansible gehen.

Gitlab CI und Ansible kombinieren

Wie bereits beschrieben nutzen wir für automatisiertes Deployment unserer Projekte aus GIT heraus Gitlab CI. Je nach GIT- Branch (bei uns sind das normalerweise „develop“, „stage“ und „master“) löst Gitlab CI unterschiedliche Aktionen aus, welche in „.gitlab-ci.yml“-Dateien in den jeweiligen Projekten definiert sind.
In der Regel werden Änderungen in den „develop“-Branches direkt per Gitlab Runner auf interne Testserver deployed. Optional können hier (und/oder bei einem Git-Push in weitere Branches) Code-Style Prüfungen oder z.B. Codeception-Tests durchgeführt werden, die dann in einem Gitlab-internen Docker-Container automatisch gestartet werden.

Änderungen an „stage“- oder „master“-Branches hingegen werden in der Regel auf externe Server ausgespielt, sei es ein geteilter Staging-Server von shoptimax oder direkt ein Kunden-System. Hier kommt dann unser Ansible-Repository mit unterschiedlichen sog. „Playbooks“ ins Spiel.

Dazu wird im ersten Deployment-Step (welcher im Docker-Container abläuft) unser internes Ansible-GIT-Repository gecloned. Dieses wird am Ende des Durchlaufs in einem sog. Gitlab CI-Artefakt gespeichert, welches in weiteren Deployment-Steps dann ebenfalls zur Verfügung steht. Damit können nacheinander die unterschiedlichen Playbooks in den verschiedenen „Stages“ des Deployments aufgerufen werden. In einer „scripts“-Sektion der .gitlab-ci.yml wird also z.B. folgendes definiert:

- git clone --depth 1 --branch master git@repo:repo_group/ansible_deployment.git ansible

Für das zu erstellende Artefakt wird weiterhin festgelegt, welche Verzeichnisse darin gespeichert werden sollen und wie lange es auf dem Gitlab-Server vorgehalten wird, z.B.

artifacts:
    paths:
    - build
    - ansible
    - deploy_scripts
    expire_in: 5 days

Diese Artefakte können vor Ablauf dieser Zeitspanne übrigens auch über die Gitlab-Oberfläche per Browser heruntergeladen werden.

In der .gitlab-ci.yml wird also definiert, wo das Ansible-Verzeichnis liegen soll und an welchen Stellen im Prozess Ansible Playbooks aufgerufen werden:

variables:
  SHOP_BUILD_DIR: "/builds/oxid/$CI_PROJECT_NAME"
deploy_stage:
  stage: deploy
  environment: deploy_stage
  tags:
    - docker
  script:
- cd $SHOP_BUILD_DIR/ansible/
- ansible-playbook -s ./deploy.yml --extra-vars "target=customer1 custom_source_folder=/../temp shop_docroot=${SHOP_DOCROOT_STAGE} shop_deploy_dir=${SHOP_DEPLOY_DIR_STAGE} ..." -vv

Timestamp-Datei für unabhängige Playbooks

Um eine gemeinsame Referenz für die unterschiedlichen Playbooks zu haben, die ja meist in verschiedenen Build-„Stages“ ablaufen (z.B. lädt das erste Playbook ein *.tar.gz hoch und packt es auf dem Server in Verzeichnis X aus, das zweite Playbook legt dann Symlinks auf dieses Verzeichnis an usw.), wird ein gemeinsamer Timestamp verwendet (z.B. auch für die Verzeichnis-Namen der Deployments). Ein solcher Timestamp wird bereits beim Clone des Ansible-Repositories erzeugt und in einer txt-Datei gespeichert:

- date +%Y-%m-%d_%H-%M-%S > ansible/timestamp.txt

In den Playbooks wird jeweils geprüft, ob es diese Datei gibt, falls ja wird der Timestamp ausgelesen und über diesen Timestamp dann das zugehörige Verzeichnis gesucht / weiter verarbeitet.
Gitlab CI cloned das Ansible Repository in einen projektspezifischen Docker-Container und speichert die Dateien im Build-Artefakt, inkl. der Timestamp-Datei.
Dadurch bleibt der Timestamp während des gesamten Deployment-Prozesses über die verschiedenen, zeitlich nacheinander ablaufenden „Stages“ quasi als „Referenz“ vorhanden und jedes Playbook operiert so auf demselben Verzeichnis.

Projektspezifische Kommandos und Symlinks in JSON-Dateien

Mit Ansible ist es sehr einfach, JSON-Dateien einzulesen und abzuarbeiten. Wir verwenden z.B. JSON-Dateien, um während eines Deployments individuelle Symlinks je nach Kundenprojekt anzulegen oder um auf dem Zielserver projektspezifische Kommandos (Shell oder auch PHP) beim Deployment auszuführen.
Z.B. kann hier ein Shell-Script aufgerufen werden, das eine Datenbank-Sicherung durchführt oder ein PHP-Script, welches das „tmp“-Verzeichnis des Shops leert, Datenbank-Views neu erzeugt oder bestimmte Module automatisch de-/aktiviert usw.
Damit müssen wir keine Fallunterscheidungen oder zusätzliche Variablen und Tasks in Ansible selbst definieren, sondern können in das Kundenprojekt einfach entsprechende JSON-Dateien in das GIT-Repository einchecken. Diese können sogar z.B. pro Git-Branch oder Zielsystem unterschiedlich sein, da die Pfade bzw. Dateinamen der JSON-Dateien im jeweiligen Deployment-Step in der „.gitlab-ci.yml“-Datei als Kommandozeilen-Parameter an das Ansible Playbook übergeben werden können.

- ansible-playbook -s ./deploy.yml --extra-vars "target=customer1 shop_docroot=${SHOP_DOCROOT_STAGE} shop_deploy_dir=${SHOP_DEPLOY_DIR_STAGE} cust_htaccess_file=.htaccess_prelive cust_config_file=config.inc.prelive.php custom_commands_path=/../src/configs/commands.json custom_symlinks_path=/../src/configs/symlinks.json" -vv

So kann es z.B. eine „commands_live.json“ und eine „command_stage.json“ im Projekt geben, in welchen jeweils unterschiedliche Shell- oder PHP-Kommandos definiert sind.

Um z.B. eine JSON-Datei mit einem Array von Kommandos einzulesen, verwenden wir im Ansible-Playbook folgendes:

commands_path: "{{ custom_commands_path | default('/files/cmds.json') }}"
commands_json: "{{ lookup('file','{{ inventory_dir }}{{ commands_path }}') | from_json }}"

Die Variable „custom_commands_path“ (Pfad zur JSON-Datei) kann per Kommandozeilen-Parameter projekt-spezifisch übergeben werden, der aufgerufene Jinja2-Filter „from_json“ liest das JSON aus der Datei in eine Ansible-Variable ein.

Das erhaltene JSON kann dann in einer Schleife („with_items“, s.u.) abgearbeitet werden, die erkannten Kommandos werden dann ausgeführt. Hier ein Beispiel für eine solche JSON-Datei:

{
  "commands":[
    {"path":"/application/views/flow/", "ctype":"shell", "cmd":"ls -altr", "stage":"prerelease", "host":"master01" },
    {"path":"", "ctype":"php", "cmd":"oxid cache:clear" }
 ]
}

Zudem kann man definieren, ob man ein Kommando „prerelease“, also vor dem eigentlichen „Aktivieren“ des Deployments (z.B. ein Backup erstellen) oder aber erst hinterher (z.B. den Cache löschen) ausführen möchte. Die Variable „host“ schränkt die Aktion optional z.B. bei einem Multi-App-Server System auf einen bestimmten Host ein.

Hier ein Ansible-Task, welcher „post-release“ Shell-Kommandos ausführt:

- name: Additional Release Shell commands
  shell: "{{ item.cmd }}"
  args:
    chdir: "{{ release_dir }}/{{ release_subfolder }}{{ item.path }}"
  with_items: "{{ commands_json.commands }}"
  register: command_result
  when:
    - item.ctype != 'php'
    - ((item.stage is defined) and (item.stage != 'prerelease')) or (item.stage is not defined)
    - ((item.host is defined) and (item.host == ansible_nodename or item.host == '')) or (item.host is not defined)

Patchen von .htaccess-Dateien

Beim Release eines Live-Shops will man in manchen Fällen den Shop kurzzeitig für Kunden „sperren“, damit die Agentur und/oder der Shopbetreiber den Shop testen, Testbestellungen ausführen usw. können. Dazu verwendet man in der Regel einen Eintrag in der „.htaccess“-Datei im Shop-Verzeichnis, welche den Zugriff auf die Website / den Shop z.B. nur für bestimmte IPs erlaubt und andere Benutzer auf einen sog. Baustellen-/Offline-Seite weiterleitet oder einen Passwort-Schutz ergänzt.

Unsere Ansible-Playbooks können optional in einem ersten Deployment-Schritt den Inhalt einer frei definierbaren Datei in die .htaccess-Datei des Shops einfügen, welche z.B. eine bestimmte IP-Freigabe enthält. Dann kann, nach Freigabe bzw. Aktivierung des neuen Deployments über das Gitlab CI Backend die Agentur bzw. der Shopbetreiber den Shop testen, um im Erfolgsfall schliesslich ebenfalls über einen Button im Gitlab-CI Backend das letzte Playbook zu starten („publish“). Dadurch wird der zusätzliche Eintrag wieder aus der .htaccess-Datei entfernt. Im Gitlab CI Backend sieht das z.B. so aus:

Die vier Haken im Bild sind die Build-„Stages“, die in der „.gitlab-ci.yml“-Datei definiert sind.
In Stage 1 wird der Shop in einem internen Docker-Container „zusammengebaut“ und ein Artefakt inkl. Ansible-Playbooks erstellt, ab Stage 2 wird Ansible aufgerufen („deploy“ – „release“ – „publish“).
In Stage 2 wird das neue Release via Ansible auf den Server hochgeladen und ein Eintrag in die .htaccess-Datei eingefügt.
In Stage 3 wird der Shop-Symlink auf das neue Deployment-Verzeichnis gesetzt und in Stage 4 wird dann schliesslich der .htaccess-Eintrag wieder entfernt und der Shop ist damit wieder frei zugänglich.

Das Einfügen in die .htaccess-Datei sieht im Playbook wie folgt aus:

- name: Add custom content to .htaccess file
  blockinfile:
    dest: "{{ release_dir }}/{{ release_subfolder }}.htaccess"
    #insertbefore: BOF
    insertbefore: "#ANSIBLE_PLACEHOLDER#"
    block: |
          {{ htaccess_include }}
    marker: "# {mark} ANSIBLE BLOCK"
  when:
    - shop_htaccess_final.stat.exists == True
    - (custom_htaccess_include_rel_path is defined) and (htaccess_include != '')

Die Variable „htaccess_include“ enthält den Inhalt der zu inkludierenden Datei, sofern vorhanden. Der Pfad zur Include-Datei kann wieder auf der Kommandozeile übergeben werden:

- ansible-playbook -s ./deploy.yml --extra-vars "... custom_htaccess_include_rel_path=/../src/configs/htaccess.inc"

Entfernt wird der zusätzliche Inhalt am Ende wieder mit folgender Task-Definition:

- name: Remove included content from .htaccess file
  blockinfile:
    dest: "{{ release_dir }}/{{ release_subfolder }}.htaccess"
    marker: "# {mark} ANSIBLE BLOCK"
    content: ""
  when:
    - shop_htaccess_patched.stat.exists == True

Wir verwenden einen Marker („#ANSIBLE_PLACEHOLDER#„) in den .htaccess-Dateien, vor welchem die Datei dann inkludiert wird. Details dazu finden sich in der Doku zum Ansible „blockinfile“-Modul.

Das war es auch schon wieder mit unserem kleinen Ansible-Exkurs, in der nächsten und letzten Folge dieser Deployment-Serie schauen wir dann Gitlab CI genauer unter die Haube!

Update PHPMailer für ältere OXID Versionen

Hintergrund

Zum Ende des vorangegangenen Jahres wurde eine Sicherheitslücke der PHPMailer-Bibliothek bekannt gegeben. Da diese auch im OXID eShop eingesetzt wird, wurde in einem ausführlichen Beitrag seitens OXID auch eine kurze Anleitung zum Update des PHPMailers auf Version 5.2.21 veröffentlicht.
Es wird darauf hingewiesen, dass durch das OXID eShop framework die Basisinstallation trotz dieser Sicherheitslücke absolut sicher ist. Einzig durch externe Frontend-Module, welche die PHPMailer- Bibliothek direkt ansprechen, besteht ein eventuelles Sicherheitsrisiko. Um diese Möglichkeit komplett auszuschließen, wird mitgeteilt, dass die Klassen class.phpmailer.php und class.smtp.php durch die aktuellste Version ausgetauscht werden sollen.
(Quelle: https://oxidforge.org/en/phpmailer-5-2-21-remote-code-execution-oxid-eshop-is-safe.html)

Update für ältere OXID eShop Versionen (< 4.9.8)

Bei älteren Installationen bis zur Version 4.9.7 reicht der Austausch der beiden Klassen jedoch nicht aus. Für den Fall, dass der Mailversand über SMTP erfolgt, sind zusätzliche Anpassungen am Code notwendig. Bis zur Version 4.9.8 wurde in den OXID Core-Klassen oxEmail sowie auch oxDb jeweils nur die PHPMailer-Klasse eingebunden.

oxemail.php:

require oxRegistry::getConfig()->getConfigParam(’sCoreDir‘) . „/phpmailer/class.phpmailer.php“;

oxdb.php:

include_once getShopBasePath() . ‚core/phpmailer/class.phpmailer.php‘;

Bei älteren Versionen des PHPMailers ist dies auch ausreichend, da die Klasse SMTP bei Aufruf der Funktion SmtpSend() in der PHPMailer-Klasse inkludiert wird:
require_once $this->PluginDir . ‚class.smtp.php‘;
In der aktuellsten PHPMailer-Bibliothek werden jedoch die einzelnen Klassen (darunter auch SMTP) nicht mehr innerhalb von class.phpmailer.php‘, sondern über eine eigene autoloader-Klasse initialisiert (Quelle: https://github.com/PHPMailer/PHPMailer/wiki/Tutorial).
Um die Funktionalität von PHPMailer bei älteren OXID eShops komplett zu gewährleisten, ist daher eine weitere Anpassung notwendig. Zusätzlich zur beschriebenen Aktualisierung, muss in den beiden OXID Core-Klassen noch class.smtp.php eingebunden werden. Der folgende Code zeigt, wie die aktualisierte Klasse SMTP in OXID, Version 4.9.7, verwendet werden kann. Für weit ältere Installationen ist es nötig, sich an der schon bestehenden Einbindung der PHPMailer-Klasse zu orientieren und diese für class.smtp.php zu adaptieren.

Klasse oxEmail (v4.9.7):

require oxRegistry::getConfig()->getConfigParam(’sCoreDir‘) . „/phpmailer/class.phpmailer.php“;
require oxRegistry::getConfig()->getConfigParam(’sCoreDir‘) . „/phpmailer/class.smtp.php“;

Klasse oxDb (v4.9.7):

include_once getShopBasePath() . ‚core/phpmailer/class.phpmailer.php‘;
include_once getShopBasePath() . ‚core/phpmailer/class.smtp.php‘;

 

Continuous Delivery mit Docker, Gitlab CI und Ansible

Im letzten Jahr haben wir bei shoptimax den Entwicklungs- und Deployment-Workflow stark optimiert, um Projekte möglichst effektiv umsetzen, automatisiert testen und Fehler vermeiden zu können, die z.B. bei manuellen Uploads oder Änderungen direkt auf dem Server auftreten können. Mit einem passenden Continuous Delivery Workflow kann man erreichen, dass Änderungen zeitnah und zuverlässig ausgespielt werden können und dass auf einem Server immer ein genau definierter Zustand herrscht. Nicht zuletzt werden dadurch auch die Entwickler entlastet, da sie sich nicht mehr um das Hochladen von Änderungen, Abgleichen unterschiedlicher Datei-Versionen usw. kümmern müssen und sie durch automatisierte Tests und Validierungen frühzeitig Feedback bekommen, sollte es Probleme im Zusammenspiel der Software geben.

Alle neuen Projekte werden seit einigen Monaten bereits mit automatisiertem Deployment und nach dem Grundsatz „Continuous Delivery“ umgesetzt, ältere bzw. größere laufende Projekte stellen wir nach und nach um.

Entwicklungs-Workflow

Grundsätzlich gilt: jeder Entwickler sollte primär in seiner lokalen Umgebung entwickeln können, wozu Docker eingesetzt wird. Der Entwickler arbeitet, testet und debugged lokal auf seinem eigenen Rechner, „committed“ und „pusht“ seine Arbeit anschliessend in unsere GIT-Versionsverwaltung, für welche wir einen internen Gitlab-Server nutzen. Im Docker-Container der Entwickler sind zudem Tools wie Blackfire.io oder XHProf sowie Xdebug verfübar.

Sobald mit GIT in den sogenannten „develop“-Branch gepusht wird, übernimmt unser Gitlab-Server das automatische Deployment auf ein internes Test-System, auf welchem dann Projektleiter oder andere Beteiligte (Grafiker usw.) den aktuellen Stand begutachten können.

Pusht ein Entwickler in den sog. „stage“-Branch, wird der Stand, nach optionalem Durchlaufen von Tests usw., auf einen externen Entwicklungsserver gespielt, z.B. auf einen Kunden-Staging-Server.

Ein Release-Manager kann schliesslich noch in den sog. „master“-Branch pushen, dieser wird dann automatisch auf den Live-Server ausgerollt, allerdings wird hier ein Feature von Gitlab CI genutzt, welches es ermöglicht, neue Deployments über die Gitlab-Oberfläche manuell per Button zu „aktivieren“ – dazu reicht ein simples

when:
– manual

in der Datei „.gitlab-ci.yml“.

So kann der genaue Zeitpunkt bestimmt werden, wann der neue Stand online geht und es können vorher z.B. noch Kontrollen durchgeführt werden. Der vorherige Stand wird auf dem Server belassen, so ist ein blitzschnelles „Rollback“ über die Gitlab-Oberfläche oder die Shell möglich, sollte es doch einmal Probleme mit der neuen Version geben.

Build und Testing

In allen drei Fällen (develop, stage und master Branch) können optional vorab in einem automatisch von Gitlab gestarteten Docker-Container z.B. Akzeptanz-Tests usw. mit Codeception durchgeführt oder Coding-Standards mittels PHP Codesniffer und ähnlicher Tools geprüft werden etc.
Ausserdem können mit einem auf „ioly“ bzw. „OXID Modulconnector“ basierenden Installer im Shop benötigte Module aus anderen GIT-Repositories oder auch von Drittanbietern automatisch installiert und aktiviert werden.
Schlägt einer der automatisierten Tests fehl, wird das Deployment gestoppt. Sind die Tests erfolgreich, wird der komplette, getestete Shop im Docker-Container als *.tar.gz gepackt.

Ausrollen mit Ansible

Im nächsten Step wird innerhalb des Docker-Containers unser Ansible-Deployment Repository aus GIT geclont.

Ansible ist eine Server-Orchestrierungs/Konfigurations-Software, womit man von einem mit Ansible ausgestatteten Rechner beliebig viele „entfernte“ Rechner/Server administrieren kann. Dazu ist auf den Remote-Rechnern keinerlei Client- oder Server-Komponente nötig, es muss lediglich ein Public Key hinterlegt werden. Die Ansible Befehle definiert man in sog. „Playbooks“, die einfach im YAML-Format geschrieben werden können.

Unser Ansible-Playbook kann nun den kompletten Shop auf beliebige Server hochladen/verteilen und diverse zusätzliche Tasks ausführen, z.B. Symlinks anlegen (die in einer JSON-Datei definiert werden können) sowie Shell- oder PHP-Befehle ausführen (ebenfalls in JSON beliebig definierbar, z.B. Tmp-Verzeichnis leeren, Datenbank-Views neu erzeugen, Module aktivieren usw.).
Abschliessend kann von Ansible automatisch oder auch manuell per Button der Symlink auf das Haupt-Shopverzeichnis geändert und so der neue Stand live geschaltet werden. Wie schon erwähnt ist auch ein schnelles Rollback kein Problem, da der vorherige Stand (sowie einige ältere Stände) noch auf dem Server vorgehalten werden.

In weiteren Blog-Beiträgen werden wir sowohl Gitlabl CI näher vorstellen als auch einige Ansible-Features näher beleuchten. Teil 2 zum Thema „Ansible“ jetzt hier lesen!

OXID Hackathon Nürnberg 2016

OXID-Hackaton

Um was geht es beim OXID Hackathon?

Den Ruf nach einem OXID Hackathon gab es schon lange – endlich wurde dazu auch ein Termin und eine passende Location im Coworking Space Nürnberg gefunden. Ziel dieses Hackathons ist es, innerhalb der beiden angesetzten Tage gemeinsam nützliche, coole und kreative Erweiterungen rund um OXID (gern auch die OXIDforge.org) herzustellen.

Wie ist der Ablauf?

Am Freitagmorgen werden die Sessionvorschläge gemeinsam angesehen und entscheiden, an welchen Themen gearbeitet werden soll. Offizielles Ende ist Samstagnachmittag/-abend. Die Teilnehmer können jedoch so lange im Coworking Space bleiben, wie sie möchten – das Gleiche gilt für Freitagabend. Wer von außerhalb anreist, wird womöglich schon am 09.11.16 in Nürnberg sein – deshalb gibt es ein Treffen zu einer kleinen Abendveranstaltung am Donnerstag. Von OXIDs Seite ist für das Catering über die Veranstaltungstage gesorgt.

Wie kann man teilnehmen?

Die Registrierung erfolgt über den Openspacer. Bitte schon jetzt Themenvorschläge einreichen, es erfolgt eine Abstimmung auf der offiziellen Seite bzw. final vor Ort, woran gearbeitet wird.

Wo kann man übernachten?

Nur 300m vom Coworking Space entfernt ist das *** Garden-Hotel. Weitere verfügbare Hotels sind hier zusammengefasst.

Veranstaltungsdetails

11.11.2016 bis 12.11.2016
ab 09:00 Uhr

Coworking Nürnberg
Josephsplatz 8
90403 Nürnberg

http://coworking-nuernberg.de

Veranstalter

OXID Community
http://oxidforge.org

EXKLUSIV bei OXID: B2B-Shopsystem-Studie im Wert von 700 Euro kostenlos!

Vor einiger Zeit haben wir in unserem Blog darüber berichtet, dass das Shopsystem unseres Partners OXID eSales zu einem der besten B2B Shopsysteme gekürt wurde. Nun kann die zugehörige Studie im Wert von 700 Euro kostenlos heruntergeladen werden.

OXID iBusinessStudie
In der Studie von iBusiness werden die besten und bekanntesten B2B-Shopsysteme bis und ab 100.000 Euro Investitionsaufwand unter die Lupe genommen, die sich für die Umsetzung verschiedener B2B-Anforderungen am besten eignen. Das ausgewogenste Verhältnis zwischen Aufwand und Leistung zeigte in der Budgetklasse bis 100.000 Euro dabei das Shopsystem OXID eSales.

Die Studie enthält wertvolles Wissen und fundierte Grundlagen, wodurch Interessierte wichtige Entscheidungen in Bezug auf die Auswahl des für ihre Anforderungen am besten geeigneten Shopsystems treffen können. Es wird gezeigt:

– worauf bei der Auswahl von B2B-Shopsystemen zu achten ist
– welches Shopsystem in welchem Segment die beste Leistung bietet
– wie die Systeme im Vergleich zu bewerten sind
– welche Dienstleister bei der Implementierung unterstützen können

Jetzt zugreifen und die Studie im Wert von 700 Euro hier KOSTENLOS herunterladen!

OXID launcht eShop 5.3: Neue Einkaufswelten wecken Shopping-Emotionen

OXID eSales hat seine Shopsoftware OXID eShop einer umfangreichen Kur unterzogen. Mit dem Launch der Release 5.3 hat das ausgereifte und hundertfach eingesetzte System nun das lang erwartete Responsive Theme „Flow“ sowie ein vollintegriertes echtes E-Commerce Content Management System „Visual CMS“ im Standard mit an Bord. „In einer zunehmend Amazon-dominierten Welt, ist es für Onlinehändler wichtig, sich mit einem einzigartigen Online-Offering klar abzuheben. Relevanter Content und emotionale Einkaufswelten auf allen Kanälen sorgen für neue Umsätze und bessere Kundenbindung“, sagt Roland Fesenmayr, Vorstand der OXID eSales AG.

oxid-news

Mit „Flow“ verkaufen auf allen Kanälen

Mit dem neuen full-responsive Design-Theme „Flow“ bereitet OXID eSales bereits out-of-the-box auch auf Smartphones und Tablets ein unverwechselbares Einkaufserlebnis. Neben der weitrechenden plattformübergreifende Darstellbarkeit des Webshops sorgen Social Media Integrationen dafür, dass alle gängigen Kanäle von facebook, twitter und Google+ über youtube bis hin zu WordPress bespielt und Kunden überall kommunikativ erreicht werden können. Über API eingebundene Schnittstellen wie Google Shopping und Google Analytics geben wertvolles Feedback zu Erfolgsmessung und Kampagnencontrolling. Das „Flow“-Theme ist mit den Shop-Versionen 4.10 (Community Edition/Professional Edition) und 5.3 (Enterprise Edition) verfügbar.

“Visual CMS” – ein echtes E-Commerce CMS

„Ein Webshop kann heute nicht mehr ein statischer Produktkatalog sein. Der Händler steht im B2C- wie auch im B2B-Geschäft unter dem Druck, seinen Kunden kontinuierlich aktualisierten, relevanten Content anzubieten. Dazu wollen wir dem Shopmanager die nötigen Mittel an die Hand geben“, erklärt Fesenmayr.
Eine Besonderheit des ab sofort im Lieferumfang enthaltenen „Visual CMS“ ist der direkte Zugriff auf Artikeldaten und ihre Einbindung in frei gestaltbare Inhalte. Diese neue Backend-Funktionalität kommt mit einer grafisch zu bedienenden Oberfläche, sodass die Händler selbst direkt im Shop Landing Pages und Kampagnen gestalten können. Auf diese Weise werden Shopdaten, Markeninhalte und verkaufsfördernde Inhalte perfekt miteinander verknüpft – es gibt keinen Systembruch mehr.

Dank der serienmäßig vorhandenen Basic Widgets ist mit nur wenigen Mausklicks eine neue zielgruppenspezifische Landingpage erstellt. Wem das nicht reicht und auch für speziellere Anforderungen entwickeln E-Commerce Agenturen auf Basis von „Visual CMS“ individualisierte Widgets. „Egal ob „basic“ oder „custom“, die Bedienung der Widgets ist ohne technische Kenntnisse möglich – wie geschaffen also für den Einzelhändler jeder Größe, der online erfolgreich sein möchte“, resümiert Roland Fesenmayr von OXID die jüngste Ausbaustufe des Shopsystems.

Die OXID eSales AG gehört zu den führenden Anbietern von E-Commerce-Lösungen und Dienstleistungen. Auf Basis der OXID-Plattform lassen sich skalierbare, modulare und hochwertige Webshops in allen Branchen, für B2B ebenso wie für B2C, aufsetzen und effizient betreiben. Im B2C-Geschäft vertrauen Unternehmen wie Porsche Design, Melitta, Trigema, Lascana, oder Intersport auf OXID. Die umfassende Lösung für B2B-Shopbetreiber nutzen unter anderem 3M, Murrelektronik oder Unilever Food Solutions. Die modulare Standardsoftware wird dabei von über 150 Solution Partnern nach Wunsch implementiert, eine stetig wachsende Open Source-Gemeinde sorgt stets für neue und marktgerechte Impulse, mit der die Software voll dem Bedarf entspricht. Webshop, Mobile und Point of Sale (POS) decken dabei das volle Multichannel-Spektrum ab.

Und jährlich grüßt die Oxid Academy

Wie bereits im vergangenen Jahr machten sich auch im diesjährigen Juni wieder einige Entwickler der shoptimax GmbH auf zum Workshop-Seminar „OXID eShop Zertifizierung Technik Modul 1 – Modul 3“.

Freuen sich über ihre erfolgreiche OXID-Zertifizierung: (v.l.n.r.) Artem Eremitschew, Vaclav Hoblik und Xiuqi Zhu

Freuen sich über ihre erfolgreiche OXID-Zertifizierung: (v.l.n.r.) Artem Eremitschew, Vaclav Hoblik und Xiuqi Zhu

Vaclav Hoblik, Artem Eremitschew und Xiuqi Zhu lernten an drei aufeinanderfolgenden Tagen in Berlin geballtes OXID-Wissen – angefangen von der sicheren Anwendung des OXID eShop inklusive Basiswissen über individuelle Anpassungsmöglichkeiten, tiefgehende Kenntnisse über die Architektur des OXID eShop, die zur Entwicklung eigener, einfacher Module befähigen bis hin zu Besonderheiten der Enterprise Edition und sich daraus ergebenden Möglichkeiten.

„Mir war es wichtig, dass nicht nur ich als Teamleiter des Bereichs Softwareentwicklung meine Kenntnisse in Bezug auf OXID eSales vertiefe und mir neue Inspiration hole, sondern dass auch Xiuqi und Artem als meine Teammitglieder von dieser wirklich ausführlichen Schulung profitieren. Natürlich arbeiten sie bereits tagtäglich mit dem Shopsystem, aber der Workshop biete eine optimale Möglichkeit, sich auch mit anderen Entwicklern einmal austauschen zu können und den eigenen Horizont zu erweitern“, so die Bilanz von Vaclav Hoblik. Nun dürfen sich die drei Entwickler von shoptimax offiziell „OXID eShop Certified Engineer (PE) & OXID eShop Certified Engineer (EE)“ nennen. Damit reihen sie sich in eine stolze Anzahl von in den vergangenen Jahren bereits über 25 durch OXID zertifizierte shoptimax-Mitarbeiter ein.

Ein unschlagbares Team – OXID eSales und shoptimax

Bereits seit 2004 ist shoptimax OXID Premium Solution Partner – seit 2013 OXID Enterprise Level Partner. Unsere Entwickler nehmen regelmäßig an Seminaren und Schulungen der OXID eSales AG teil, um immer auf dem neuesten Stand zu bleiben und die bestmöglichen Lösungen aus dem Shopsystem für unsere Kunden erarbeiten zu können.

Einer der Hauptschwerpunkte unserer Arbeit liegt auf der Entwicklung von OXID Modulen für die unterschiedlichsten Anwendungsmöglichkeiten und der Implementierung des Shopsystems in die ERP- und PIM-Backendsysteme unserer Kunden. Eine besonders beliebte Schnittstelle ist beispielsweise OXID2plentymarkets, die offiziell autorisierte Schnittstelle zwischen OXID und der E-Commerce-Warenwirtschaft plentymarkets.