Deployment von Shopware in Multistage Environments

Deployment: Automatisch, praktisch, gut!
Keine Kommentare

Für viele Shopbetreiber und Agenturen ist ein automatisches Shopware Deployment immer noch ein Buch mit sieben Siegeln. Viele behaupten, es sei zu aufwendig oder würde nicht vom Kunden bezahlten werden. Dass das aber nicht stimmt und dass mit ein wenig Konfigurationsaufwand ein einfacher Deployment- und Rollback-Prozess möglich ist, zeigt Thomas Eiling.

Für viele Shopware-Entwickler sieht ein „typischer“ Deployment-Prozess immer noch wie folgt aus:

  • Hochladen der Änderungen
  • Installation/Update von Plug-ins
  • Konfiguration der Plug-ins/Grundeinstellungen
  • Cache leeren
  • Prüfen ob alles wie erwartet funktioniert

Das ist nach meinem Dafürhalten eine ziemlich lästige Art, eine neue Softwareversion auszuliefern. Zusätzlich ist es durch die vielen manuellen Schritte sehr fehleranfällig. Wie wäre es, wenn wir all diese Schritte mit einem einzigen Shell-Command erledigen könnten? In den folgenden Abschnitten stelle ich euch ein Script vor, mit dem Ihr viele Anforderungen an ein automatisches Deployment erledigt. Das vollständige beschriebene Script könnt ihr auf GitHub finden.

Voraussetzungen

Die benötigten Voraussetzungen für so ein Deployment sind gering. Wir benötigen Shopware 5.4 oder aktueller und müssen die Composer-Installation verwenden. Zusätzlich sollte sich PHP 7.0 oder aktueller auf dem Server befinden. Um einen reibungslosen Rollback zu einer vorherigen Version zu ermöglichen, müssen sich alle Entwickler und die Entwickler von Drittanbietersoftware bewusst sein, dass das Blue-Green Deployment umgesetzt wird. Shopware unterstützt dies von Haus aus seit der Version 5.4.

Auf der Serverseite benötigen wir mindestens SSH-Zugriff und eine Verzeichnisstruktur, wie sie in Listing 1 beschrieben ist. Der symbolische Link httpdocs ist als DocumentRoot konfiguriert und weist auf die aktuell ausgelieferte Softwareversion. Im Verzeichnis media werden alle statischen Daten von Shopware gespeichert. Diese sind wiederum durch einen symbolischen Link im ShopwareDocumentRoot verknüpft.

httpdocs → 1.0.1
  1.0.0
1.0.1
  - media → ../media
media

Blue-Green Deployment

Die Möglichkeit, die Produktivumgebung einfach up- und downgraden zu können wird allgemein als Blue-Green Deployment bezeichnet. Jede neue Version darf keine destruktiven Änderungen in einem Deploymentschritt ausführen, um einen einfachen Rollback zu ermöglichen. Das bedeutet, dass die neueste Datenbankversion immer noch mit der vorherigen Softwareversion einwandfrei funktionieren muss und es darf durch einen Rollback kein Datenverlust entstehen.

International PHP Conference 2018

Getting Started with PHPUnit

by Sebastian Bergmann (thePHP.cc)

Squash bugs with static analysis

by Dave Liddament (Lamp Bristol)

API Summit 2018

From Bad to Good – OpenID Connect/OAuth

mit Daniel Wagner (VERBUND) und Anton Kalcik (business.software.engineering)

Durch dieses Prinzip benötigt eine Namensänderung an einer Datenbankspalte mindestens drei separat deployte Softwareversionen. In der ersten Version wird eine neue, korrigierte Spalte angelegt. Die Daten aus der alten Spalte werden in die Neue übernommen und durch einen Datenbanktrigger aktuell gehalten. In der zweiten Version wird nun die neue Datenbankspalte verwendet und durch ein Datenbank-Connection-Parameter ändert der Trigger die Speicherrichtung von „Altespalte → Neuespalte“ in „Neuespalte → Altespalte“. Im letzten Schritt wird die nun nicht mehr benötigte alte Datenbankspalte inklusive der Trigger entfernt.

Ablauf des Deployments

Um ein Deployment anzustoßen, reicht es aus, folgenden Command auf der Konsole auszuführen: ./psh.phar deploy –ver 1.0.1. Wer detaillierte Informationen zu dem Tool PSH haben möchte, dem kann ich die PHP-Magazin-Ausgabe 3.17 mit dem Titelthema „Plates“ wärmstens ans Herz legen.

Unser Befehl baut unser neues Softwarepackage auf Basis des konfigurierten Repositorys. Durch die verwendete Composer-Installation von Shopware müssen wir uns um folgende Schritte im Deployment nicht kümmern:

• Erstellung aller benötigten symbolischen Links für Plugins, Themes usw.
• Ausführung der Migrations
• Cache leeren
• Themes generieren
• alle vorhandenen Plug-in-Updates ausführen

Im Abschluss findet das Wechseln der Softwareversion statt. Hierbei wird unser symbolischer Link auf die aktuelle Version umgestellt und schon ist die neue Softwareversion online. Klingt ziemlich einfach, oder? Wie sieht das Ganze aber im Detail aus?

Deployment

PSH führt die in Listing 2 zu sehende deploy.sh aus. Wie man dort sehen kann, besteht das ganze Deployment aus sechs einzelnen Shell-Commands. Die in den Skripten zu sehenden Platzhalter – z. B. __VER__, 0– werden durch psh mit den jeweiligen Konstanten aus der .psh.yaml (Listing 3) und den gegebenenfalls vorhandenen Konsolenparametern ersetzt. Dies führt dann dazu, dass wir im ersten Schritt unser Repository in das konfigurierte Verzeichnis klonen. Hierbei greifen wir auf die vorher angegebene Version (git tag) zurück.

#!/usr/bin/env bash
git clone --branch __VER__ __GIT_REPO__ __CHECKOUT_DIRECTORY__/__VER__
cd __CHECKOUT_DIRECTORY__/__VER__ && composer install
cd __CHECKOUT_DIRECTORY__/__VER__ && ln -s media ../media
ln -s __CHECKOUT_DIRECTORY__/media __CHECKOUT_DIRECTORY__/_VER__/media
rm -f __CHECKOUT_DIRECTORY__/__DOCROOT__
ln -s __CHECKOUT_DIRECTORY__/__VER__ __CHECKOUT_DIRECTORY__/__DOCROOT__
paths:
  - dev-ops
const:
  GIT_REPO: "git@github.com:shopware-blog/shopware-deployment-installation.git"
  CHECKOUT_DIRECTORY: "/var/www/shopwaredemo.de"
  DOCROOT: "httpdocs"

Nun haben wir unser Shopware-Skelett auf dem Server und werden es mit Leben füllen, indem wir die notwendigen Abhängigkeiten mithilfe eines composer install beziehen. Dies führt dazu, dass Composer die in „Ablauf des Deployments“ beschriebenen einzelnen Schritte ausführt und somit unsere Software nun aktuell ist. Da wir die Mediadaten der Artikel und vieles Weitere natürlich nicht in unserem Repository haben, verlinken wir diese einfach in das neu erstellte ShopwareDocRoot, um bei einem Switch direkt alle Bilder ausliefern zu können. Zum Abschluss entfernen wir den aktuellen Symlink und erstellen einen neuen, der auf die aktuelle Version unserer Software verweist.

Rollback

Um ein Rollback zu einer vorherigen, bereits deployten Version durchzuführen, müssen wir nur ./psh.phar rollback –ver 1.0.0 auf der Konsole ausführen. Wie auch das vorherige Skript besteht dieses (Listing 4) aus einer Ansammlung einzelner Commands, die mit Platzhaltern individualisiert werden.

#!/usr/bin/env bash
I: rm __CHECKOUT_DIRECTORY__/__DOCROOT__
ln -s __CHECKOUT_DIRECTORY__/__VER__ __CHECKOUT_DIRECTORY__/__DOCROOT__

Wir entfernen den aktuellen Symlink und erstellen einen neuen Symlink, der auf die vorherige Software-Version 1.0.0 verweist. Damit ist das Rollback schon abgeschlossen. Der Vorteil dieser Art von Deployment ist, dass wir keine Downtime während eines Deployments oder Rollbacks haben. Wir wärmen den Cache beim Deployment auf und bei einem Rollback können wir den bereits vorhandenen Cache direkt wieder verwenden.

Einstellungen

Wir wissen nun, wie wir einfach neue Software und Plug-ins via Composer und einigen Shell-Commands ausliefern können. Wie aber können wir auch die Grundeinstellungen von Shopware oder Konfigurationen von Plugins deployen, ohne dies manuell im Shopware Backend jedes Mal einstellen zu müssen?

Hierfür gibt es das Plug-in Environment Variables, das der Shopware-Community entsprungen ist. Mit dieser Erweiterung können wir kinderleicht die Grundeinstellungen und/oder Plug-in-Konfiguration über die config.php überschreiben. Eine beispielhafte Konfiguration für das Überschreiben einer Plug-in-Konfiguration könnt ihr in Listing 5 finden.

<?php return [
  'db' => [...],
  'custom' => [
    'plugins' => [
      1 => [
        'SwagPaymentPaypal' => [
          'paypalUsername' => getenv('paypalUsername'),
          'paypalPassword' => getenv('paypalPassword'),
        ],
      ],
    'config' => [
      1 => [
        'setoffline' => true,
      ],
    ],
];

Im bereits bekannten Arrayindex db wird ein weiterer Index namens custom hinzugefügt. Darunterliegend gibt es dann den Index plugins mit einem nummerischen Index. Die dort hinterlegte Nummer steht für die für diese Konfiguration gültige ShopID. Nun folgen der Pluginname, config-Key und der zu überschreibende Konfigurationswert.

Hierbei kann man festkodierte Werte oder dynamische aus Umgebungsvariablen verwenden. Dies hat den Vorteil, dass man umgebungsspezifische aber auch versionsspezifische Konfigurationen vornehmen kann. Beispielsweise möchte man auf der Dev- und Stage-Umgebung den Wartungsmodus aktiviert haben (setoffline = true), aber nicht in der Liveumgebung.

Um das Erstellen eines Configurationarrays so einfach wie möglich zu machen, bietet das Plug-in ein Konsolen-Command, mit dem man eine exemplarische config.php generieren kann, in der alle Shops, Grundeinstellungen und Pluginkonfigurationen vorhanden sind. Somit muss man im Anschluss nur noch die gewünschten Konfigurationswerte anpassen.

E-Mail-Vorlagen

Jeder, der schon einmal E-Mail-Vorlagen in Shopware bearbeiten und ins Livesystem übernehmen durfte, weiß, was das für eine Sisyphusaufgabe ist. Auch für diese Herausforderung hat die Shopware-Community ein Plugin, FroshTemplateMail, entwickelt, das uns die Arbeit deutlich vereinfacht. Diese Erweiterung führt ein weiteres Verzeichnis, eMails, in unsere Theme-Struktur ein. In diesem Verzeichnis können für die jeweiligen E-Mail-Vorlagen einzelne *.tpl-Dateien für Betreff, Plaintext, HTML usw. erstellt werden.

Zusätzlich können diese E-Mail-Vorlagen auch shopspezifisch erstellt und verwaltet werden. Das Allerbeste aber ist, dass von nun an die E-Mail-Vorlagen in unserer Versionsverwaltung vorliegen. Kein lästiges Datenbank-Back-up herunterladen und lokal wiederherstellen, um eine vom Anwender gelöschte oder veränderte Vorlage reparieren zu können.

Destruktive Datenbankänderungen

Wie im Abschnitt „Blue-Green Deployment“ zu lesen ist, sind destruktive Datenbankänderungen in einem Deployment-Schritt nicht zulässig. Wie aber kann ein exemplarisches Szenario aussehen, in dem wir eine Datenbankspalte umbenennen und trotzdem das „Blue-Green Deplyoment“ berücksichtigen? Im ersten Schritt müssen wir eine neue Spalte mit den neuen Wunschnamen unserer Datenbanktabelle hinzufügen. Anschließend kopieren wir die vorhandenen Daten aus der alten Spalte in die neue. Um die neue Spalte aktuell zu halten verwenden wir einen Trigger (Listing 6), der bei Updates die Werte von der alten in die neue Spalte schreibt.

Im zweiten Schritt wird der Quellcode angepasst und nun die neue Spalte verwendet. Um einen reibungslosen Wechsel der Versionen ohne Datenverlust zu ermöglichen, muss unsere Software natürlich die eingesetzte Softwareversion in der Database Connection setzen. Mit @version prüft der Trigger, welche Softwareversion im Einsatz ist und wechselt gegebenenfalls die Richtung von „Alt → Neu“ zu „Neu → Alt“. Im letzten Schritt werden der erstellte Trigger und die alte Datenbankspalte entfernt.

CREATE TRIGGER before_update
  before UPDATE on table_name
  FOR EACH ROW
  begin
  if @version = '1.0.0' then
    set new.new_column = new.old_column
  end if;
  if @version = '1.0.1' then
    set new.old_column = new.new_column
  end if;
end;

Abschließend

Durch die Wiederverwendbarkeit und Parametrisierung der Shellskripte mithilfe von PSH ist es ein Leichtes, das Deployment auf verschiedene Umgebungen anzuwenden. Hierzu müssen wir nur die psh.yaml um die jeweiligen Environments ergänzen und gegebenenfalls notwendige Zugriffe hinterlegen. Hier könnt Ihr dafür Beispiele finden.

Es existieren Lösungen für die häufigsten Probleme bei einem automatischen Shopware Deployment. Somit gibt es auch meiner Meinung nach keine Ausreden mehr, das nicht zu tun. Die Lernkurve dabei ist ziemlich steil. Sobald einmal die Grundlagen dafür geschaffen sind, fängt man kontinuierlich an, auch noch den kleinsten manuellen Schritt zu automatisieren. Selbst wenn Ihr nur ein paar Schritte eines Deployment-Zyklus in Verwendung habt, spart Ihr Zeit und verschafft Euch einen Vorteil gegenüber Euren Mitbewerbern.

PHP Magazin

Entwickler MagazinDieser Artikel ist im PHP Magazin erschienen. Das PHP Magazin deckt ein breites Spektrum an Themen ab, die für die erfolgreiche Webentwicklung unerlässlich sind.

Natürlich können Sie das PHP Magazin über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist das Entwickler Magazin ferner im Abonnement oder als Einzelheft erhältlich.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -