Deployment-Prozess eines Magento-Shops

Um ein möglichst einfaches und fehlerfreies Updaten eines Magento-Shops zu gewährleisten, müssen viele verschiedene Aspekte beachtet werden.  Im Folgenden sei hier beschrieben, welche Überlegungen wir uns zu dem Thema gemacht haben und zu welcher Lösung wir gekommen sind.

Ich vermute, jede Firma/jeder Entwickler hat seine eigene Lösung entwickelt, die notwendigen Aktualisierungen eines Magento-Shops vorzunehmen. Das ist auch durchaus logisch, da es in jedem Projekt unterschiedliche Anforderungen zu erfüllen gilt. Hinzu kommt, dass größere Magento-Dienstleister durchaus dazu bereit sind, einige Monate Entwicklungszeit in einen ausgereiften Deployment-Prozess zu investieren. Für kleinere Betriebe ist jedoch eine weniger umfangreiche und dennoch leistungsstarke Lösung interessanter, die dem Aufwand effizient gerecht wird und sich flexibel an verschiedene Projekte und Anforderungen anpassen lässt.

Vorraussetzungen

Ohne Versionierung geht nichts

Vorbei sind die Zeiten, wo ein Entwickler noch alleine an einem Projekt programmiert hat und die volle Verantwortung für das regelmäßige Backup des Source-Codes trug. Heutzutage empfiehlt es sich, alle Entwicklungsschritte per Subversion zu dokumentieren. So ist es durchaus komfortabel, nachvollziehen zu können, welche Änderungen in der Vergangenheit wann und aus welchem Grund gemacht wurden. Oder wissen Sie noch genau, an welcher Datei Sie vor vier Wochen den Bug XY beseitigt haben?

Ein Hinweis zum Umgang mit Subversion: Auf dem Liveserver selbst sollten keine .svn-Dateien liegen, da wir nicht auf dem Liveserver mit svn-Befehlen hantieren oder gar Versionierungskonflikte lösen wollen.

Mehrere Installationen

Für gewöhnlich gibt es mehrere Installationen eines Shops, verschiedene Test- und Entwicklungssysteme sowie natürlich die auf dem Liveserver. Auf jeder Installation gibt es lokale Anpassungen (wie z. B. die Base-Url) und temporäre bzw. installationsspezifische Dateien (var-Verzeichnis). Nicht zu vergessen: die Datenbank. Es soll möglich sein, ohne großen Aufwand den Dump einer anderen Installation (z.B. vom Liveserver) lokal einzuspielen, ohne dabei jedes Mal eine Vielzahl von Einstellungen anpassen zu müssen.

Unsere Lösung

Installation des Live- und Testservers

Die Live- und Testserver bestehen jeweils nur aus den installationsspezifischen Dateien, der eigentliche Source-Code wird durch Symlinks in die Installation "eingespeist". So kann man allein durch das Ändern eines Symlinks die komplette Installation auf eine neue Version updaten. Das hat den Vorteil, dass es sehr schnell geht (wenige Millisekunden) und dass es sich auch leicht wieder rückgangig machen lässt.
Folgende Dateien und Order sind auf diese Weise verlinkt:
    * app/code
    * app/design
    * app/locale
    * app/etc/modules
    * js
    * lib
    * skin
    * index.php
Ausgenommen ist allerdings die Datei Mage.php, die nicht verlinkt werden kann, da sonst temporäre Dateien an die falsche Stelle geschrieben werden.

Konfiguration in local.xml

Man findet im Internet diverse Anleitungen, welche Konfigurations-Tabellen man per SQL wie bearbeiten muss, wenn man sich den SQL-Dump einer anderen Installation eingespielt hat. Das ist im Falle der Basis-Url noch relativ schnell gemacht. Doch wenn man z.B. auch die verschiedenen Email-Adressen anpassen muss, wird es schnell zu einer nervigen Aufgabe. Um dies zu umgehen, gibt es eine relativ einfach Lösung: Man schreibt die abweichenden Konfigurationen in die local.xml. Das klappt allerdings nur mit einem kleinem Trick. Hierfür verantwortlich ist, wie Magento mit Konfigurationseinstellungen umgeht:
Grundsätzlich werden Konfigurationseinstellungen, die in XML-Dateien stehen, von den Einstellungen in der Datenbank überschrieben. Demzufolge funktioniert das Überschreiben in der local.xml nicht. Da die meisten Einstellungen aber nur für den Default-Scope in der Datenbank stehen und für die einzelnen Stores vererbt werden, kann mit der Angabe des Stores in der local.xml die Default-Einstellung doch überschrieben werden. Das sieht dann in der local.xml beispielsweise so aus:


<config>
    <global>
    <!-- ... -->
    </global>
    <stores>
        <default>
            <web>
                <unsecure>
                    <base_url>http://beispiel.tld/shop/</base_url>
                </unsecure>
        </default>
        <admin>
            <web>
                <unsecure>
                    <base_url>https://beispiel.tld/shop/</base_url>
                </unsecure>
        </admin>
    </stores>
</config>


Wurden so erstmal alle Einstellungen vorgenommen, kann man anschließend Datenbank-Dumps nach Belieben hin- und herspielen, ohne Konfigurationsprobleme zu bekommen.

Fazit

Insgesamt ist diese Art des Deployments effizient und sicher. Um sich vor unschönen Überraschungen zu schützen, kann die hier beschriebene Vorgehensweise eine große Hilfe sein. 

Webentwicklung & E-Commerce: Wir realisieren und optimieren Internetprojekte. Unser Fachgebiet sind Onlineshops, Rich Internet Applications und anspruchsvolle Onlineauftritte. Über unsere Arbeit schreiben wir. Hier im Blog von TUDOCK.