Abenteuer Magento-Update – ein Erfahrungsbericht

Vor kurzem haben wir für einen Kunden ein Magento-Update von Version  1.7.0.2 (CE) auf 1.9.1.0 durchgeführt. Aus Erfahrungen wussten wir, dass selbst noch viel kleinere Versionssprünge manchmal große Schwierigkeiten mit sich bringen können. Dennoch haben wir uns furchtlos wie Bear Grylls in das Abenteuer gestürzt… ;)

Ausschlaggebend dafür waren hauptsächlich die vielen Bugs, allem voran das Cent-Rundungsproblem, das wir zwar gut in den Griff bekommen haben, dessen Nachwirkungen aber noch vereinzelt zu spüren waren (etwa bei Gutschrifterstellung).

Exkurs: Die Versionspolitik von Magento

Hinter den Versionsnummern lauert schon die erste Falle. Nicht-Insider sollten zuerst wissen, dass die Versionspolitik von Magento von etablierten Vorgehensweisen im Software Engineering abweicht. Die Semantic Versioning Specification etwa empfiehlt das Muster MAJOR.MINOR.PATCH. Bei Magento muss man gedanklich das vordere "1." ausblenden, dann kommt es in etwa darauf hin. Dh mit anderen Worten: was täuschend nach einem Minor-Update aussieht, entspricht in Wahrheit einem Major-Sprung von 2 Versionsnummern.  In Major-Sprüngen sind nicht-rückwärtskompatible API-Änderungen erlaubt, in Minor-Sprüngen nicht. Aber auch hier haben wir schon in einer älteren Magento-Version gesehen, dass auch hier einiges schiefgehen kann (ich glaube es war 1.4.0 auf 1.4.2 o.ä.).

Die Vorbereitung

Um einen reibungslosen Ablauf garantieren zu können, war es für uns wichtig, dass der Update-Prozess folgende Kriterien erfüllt. Er muss…

• stabil,
• reproduzierbar
• und möglichst schnell durchführbar

sein. Außerdem ist für uns die Versionierung in einem Code Repository ein weiteres wichtiges Kriterium. Jedes einzelne dieser Kriterien schließt also schon einmal vorweg den Einsatz von automatischen Updates über Magento Connect aus.

Wir haben uns daher zu folgender Vorgehensweise entschlossen:

1. ein Update-Paket zusammenstellen, das das komplette File-Verzeichnis (mit Ausnahme von media, var Verzeichnissen) der neuen Version inklusive aller Third Party und eigenen Extensions und Themes beinhaltet.
2. Durchführung des Updates auf einem Testsystem (niemals direkt auf dem Produktivsystem!)
3. Testen und Durchführung der notwendigen Anpassungen in eigenen Templates und Modulen (selbstverständlich auch unter Berücksichtigung von Hinweisen in den Release Notes).
4. Update diverser Third-Party Extensions
5. Sobald alles wieder funkioniert: Update  des Live-Systems

Klingt eigentlich logisch und einfach, ist es aber leider nicht. Nachfolgend einige Gründe, die einem hier das Leben erschweren und das Update zu einem richtigen Abenteuer machen.

Fragmentierung

Bei der Zusammenstellung des Update-Pakets, sowie bei der Aktualisierung der Extensions, ist das massivste Problem die Fragmentierung der Verzeichnisse. Selbst, wer nur ein eigenes Theme erstellt, ohne irgendwelche Funktionalität zu verändern oder zu ergänzen, indem er eigene Extensions bereitstellt, muss seine Dateien einerseits innerhalb des app/design/frontend und andererseits innerhalb des skin/frontend Verzeichnisses platzieren.

Bei Modulen ist das noch viel schlimmer. Selbst kleinste Module verteilen ihre Dateien zumindest unterhalb von app/etc/modules and app/code/local (bzw community), meistens kommt jedoch auch noch (ein tiefes Unterverzeichnis) von app/design/frontend, app/design/admin und app/locale dazu. Nicht selten folgt auch noch skin/frontend und/oder skin/admin. Das ist aber noch nicht alles. So manche Extension muss auch noch Dateien im js Ordner ablegen. War’s das? Nein, da geht noch mehr! Es gibt ja auch noch den lib-Ordner. Ein eigener Unterordner dort ist aber nur etwas für Weicheier – für Hartgesottene gibt es auch noch Verstecke wie lib/Varien/Data/Form/Element!

Ein saubere Code-Versionierung der eigenen sowie fremden Erweiterungen ist hier nicht nur hilfreich, sondern Pflicht, um überhaupt noch eine Chance auf einen Überblick zu haben.

Folgenschwere API-Änderungen

Nun sollte man ja eigentlich meinen, dass etwaige API-Änderungen bei dem vermeintlich kleinen Versionssprung, die die eigenen Erweiterungen betreffen, schnell angepasst sind, wenn man immer brav dem Prinzip gefolgt ist, dass man niemals (bzw nur in äußersten Notfällen, wenn eine Fehlerbehebung oder Anpassung nicht durch Überschreibung/Vererbung nicht möglich ist) den originalen Quelltext anfasst, sondern alle Anpassungen und Erweiterungen durch eigene Module und Themes löst, mit Hilfe von Rewrites, Event-Handlern, etc.

Aber leider hat man auch hier die Rechnung ohne den Wirt gemacht. Zwischen 1.7 und 1.9 wurden tiefgreifende Änderungen im E-Mail Templating und bei den Formularen (Token) gemacht. Dh mit anderen Worten: man muss alle angepassten E-Mail Templates überprüfen und anpassen, sowie so gut wie alle Templates (weil ja auch fast überall ein Formular zu finden ist). Letzteres ist vor allem dem schwachen Template-Layer von Magento geschuldet. Template-Engine/Prozessor oder zumindest eine Abstraktionsschicht für den Aufbau und das Rendering von Formularen? Fehlanzeige! Dafür wird das bunte Gemisch aus HTML- und PHP-Code noch garniert mit einer Prise Business Logic in den Templates. Das Preis-Template von Artikeln z.B. könnte man glatt bei einem Code Obfuscation Contest einreichen.

Die Release Notes von Magento sind übrigens grundsätzlich ziemlich lang und detailliert, wesentliche Hinweise fehlen jedoch trotzdem. Große Aufmerksamkeit erhalten eigentlich nur Dinge, die marketing-technisch gut rüberkommen, wie etwa die Überarbeitung der Steuerberechnung. Warnhinweise, dass die oben erwähnten Anpassungen einen Großteil der Templates betreffen, fehlen vollständig – das würde ja auch nicht gut klingen.

Fazit

Letztendlich ist dank guter Vorbereitung alles gut verlaufen. Müde und leicht fertig mit den Nerven kann man sich danach entspannt zurücklehnen und sich ein bisschen wie ein Abenteurer fühlen, ein Bear Grylls der Webentwickler quasi...

Folgende Erkenntnisse möchte ich noch festhalten:

Mit steigender Individualität einer Magento-Installation (eigene Module, Templates, etc) steigt der Update-Aufwand progressiv an. Shops, die Magento „out of the box“ auskommen tun sich erheblich leichter bei der Aktualisierung. Unterschätzen Sie keinesfalls den Aufwand! Was Sie auf jeden Fall benötigen, ist viel Zeit, eine penible Vorbereitung, gute Nerven und natürlich ein Testsystem, auf dem Sie den Update-Prozess durchspielen und gegebenenfalls Anpassungen vornehmen können, bevor Sie Ihr Produktivsystem aktualisieren.

Grundvoraussetzung für ein Magento-Update. ist außerdem, dass Sie einen vollständigen Überblick über das laufende System haben, dh welche Dateien wurden wo hinzugefügt oder verändert. Ohne Versionierung in Git oder Mercurial können Sie das vergessen. Von einem Blindflug würde ich dringend abraten! Das Risiko ist also groß, dass man ohne entsprechende Dokumentation in einer alten Version festsitzt. Der Aufwand des Updates ist dann nämlich überhaupt nicht mehr kalkulierbar, auch Nebenwirkungen wie verlorene Funktionalität oder das Auftreten von Bugs sind dann sehr wahrscheinlich. In diesem Fall sollte man sich ernsthaft damit auseinandersetzen, ob ein Neubeginn nicht die bessere Alternative wäre. Und hier würde ich dringend empfehlen, sich auch mit anderen Shopsystemen auseinanderzusetzen, insbesondere Drupal Commerce.