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. 

Kommentare

14.10.2010 15:25Magnus
Google translation to english
14.10.2010 19:55Regine Voigthttp://www.tudock.de
Hello Magnus,

I took the liberty to replace the google translation with an edited version...
Magento deployment process: How to upgrade your Magento store

To ensure a simple and error-free updating process of a Magento store, many different aspects must be considered. I will describe here our considerations on the subject and the solution to which we have come.

I guess every company/each web developer has come up with its own solution to make the necessary updates to a Magento shop. That’s a matter of course as different requirements are met with in each project. In addition, greater Magento agencies are quite willing to invest several months of development time into a mature deployment process. For smaller companies however a less extensive and yet efficient solution is more desirable which can be adapted to varying projects with different nee
Assumptions
Versioning is indispensable

Gone are the days when a developer has coded for a project single-handedly and bore the full responsibility for the regular backup of the source code. Today it is advisable to document all steps of development by subversion. Therefore you will be able to retrace past changes and recollect when and for what reason they were made. Or do you remember exactly which file you have worked on four weeks ago in order to delete the bug XY?

A note on dealing with subversion: There should be no .svn files on the live server because we do not want to tamper with svn commands here or end up with versioning conflicts on the live system.
Several installations

Usually there are multiple installations of a shop, various test and development systems and of course the ‘online system’ on the live server. For each installation there are local adaptations (such as the base URL) and temporary or installation-specific files (var directory). Not to forget: the database. The goal is to achieve a solution where it is possible to easily implement the dump of another installation (e.g. from the live server) locally without having to adjust each time a variety of settings.
Our solution
Installation of the live and the test server

The live and test servers solely consist of the installation-specific files - the actual source code is fed into the installation with symlinks. Thus you can update your magento store simply by changing a symlink. This procedure has the advantage of being very fast (it takes just a few milliseconds) and of being reversible.

The following files and folders are accordingly linked:

* app/code
* app/design
* app/locale
* app/etc/modules
* js
* lib
* skin
* index.php

An exception is the file mage.php, which cannot be linked, because otherwise temporary files would be stored in the wrong place.
Configuration in local.xml

On the internet you can find various instructions explaining how to edit which configuration tables via SQL, if you implemented the SQL dump of another installation. In case of the base-Url this is done relatively fast. But for example having to customize various email addresses can easily become a pesky problem. To avoid this, there is a comparatively simple solution: Write the different configurations in the local.xml. In order to circumvent further complications you need to apply a small trick. Responsible for this is how Magento handles configuration settings:

Basically, configuration settings which are stored in XML files will be replaced by the settings in the database. Therefore overriding is not working in local.xml. But as most of the settings are specified only for the default scope in the database and as they will be passed on for the individual stores, the default setting may be overridden by specifying the stores in the local.xml.

Here is an example for the modified local.xml:

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

When you have carried out all the settings, you can toggle database dumps at will without evoking configuration problems.
Conclusion

In a nutshell this type of deployment is efficient and secure. In order to avoid unpleasant surprises the procedure described here should be a big help.
30.10.2010 21:55Jens Holzehttp://www.blooparksystems.de
Guter Beitrag. Kleine Info, zur Meet Magento veröffentlichen wir Mavento. Magento Deployment mit Maven & Ant.


Jens
26.01.2011 22:09Robert Erlingerhttp://blog.databyte.at
Soweit mir bekannt ist, sind auch in der Datenbank noch Änderungen hinsichtlich des Hosts zu machen. D.h. den Dump 1:1 einzuspielen ist nicht ohne Modifizierung möglich.
27.01.2011 09:26Felix Krügerhttp://www.tudock.de
Vielen Dank für die Kommentare....


Mit dem oben beschriebenen "Trick" kann man tatsächlich den MySQL-Dump ohne Modifizierung auf einer anderen Installation verwenden. Ausprobieren lohnt sich ;) Wir arbeiten jetzt schon seit knapp einem Jahr mit dieser Vorgehensweise.
03.02.2011 12:19Jamie
Thank you for this great post. I never knew this was possible! This will make importing the live database into my development database much easier. The last thing to make this complete would be to disable the cache in this file also. Does anybody know how to override the cache setting in the database from app/etc/local.xml?


Google Übersetzung:

Vielen Dank für diese tolle Post. Ich wusste nie, das war möglich! Damit wird dem Import der Live-Datenbank in meiner Entwicklung Datenbank viel einfacher. Das letzte, was um diese komplett wäre, um den Cache in dieser Datei auch deaktivieren. Weiß jemand, wie der Cache-Einstellung in die Datenbank von app / etc / local.xml überschreiben?
17.05.2011 14:58Felix Krügerhttp://www.tudock.de
Hallo Jamie,


unfortunately it's not possible to overwrite the cache settings in this way, because these settings are not present in the global XML-Configuration. They are saved directly in the database.

This ist necessary because the XML-Configuration could be cached and when the caching-configuration would be saved in this cached File, you will not be able to change the settings ;)
12.02.2012 17:32Steven Fritzschehttp://www.mediarox.de
Seit ein paar Tagen ist das erste public release von mavento online.
http://mavento.bbe-consulting.de/
Ein Opensource Deploymenttool speziell für Magento auf Basis eines Maven-Plugins.

Beitrag kommentieren

* *
*
* Notwendige Angabe

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.