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.

Kommentare5

Klartext

  • Keine HTML-Tags erlaubt.
  • Zeilenumbrüche und Absätze werden automatisch erzeugt.
  • Website- und E-Mail-Adressen werden automatisch in Links umgewandelt.
Der Inhalt dieses Feldes wird nicht öffentlich zugänglich angezeigt.

Nick

vor 8 years 8 months

Leider zu theretisch
Komme mir vor wie an der UNI. Toller Artikel der praktisch nischt aussagt. :-( Gruss NH
Never update Magento

Hi Nick,

danke für deinen Comment. Kurz zusammengefasst würde ich die Aussage auf "Magento ist beinahe unupdatebar und der Aufwand ist beträchtlich. Verbrennt euch nicht die Finger dabei und lasst es bleiben, wenn ihr keine genauen Aufzeichnungen darüber habt, was alles angepasst und/oder erweitert worden ist"

Guter Post, der sich mit meinen Erfahrungen deckt
Magento ist meiner Meinung nach ein System für Firmen mit eigener eCommerce-IT-Abteilung oder sehr, sehr großem Budget bzw. entsprechend hohem Umsatz. Für kleinere Shops wird der Update-Aufwand definitiv zu hoch, sobald individuelle Anpassungen gemacht wurden. Völlig unkalkulierbar wird es mit dem Einsatz von Fremd-Extensions. Auf lange Sicht ist es besser, wenn die Extensions und Templates selbst entwickelt wurden. So kann man alles optimal auf die eigenen Bedürfnisse anpassen, kennt sich im Quellcode aus, und ist vor ungewünschten Funktionsänderungen durch Updates von Fremd-Extensions geschützt. Aber letztendlich hängt es immer davon ab, wie weit man den Shop individualisieren muss und wie viel Budget dafür zur Verfügung steht. Ich habe gerade ein Update von 1.3 auf 1.9 hinter mir. Der Shop war 3 Stunden offline. Die meiste Zeit davon hat die automatische Änderung der Datenbankstruktur benötigt. Ohne minutiöse Vorbereitung und mehrfach getestete Update-Strategie wäre das Update so nicht möglich gewesen. Die Kunden nehmen die neue Version sehr gut an. Insofern hat sich der Aufwand sicher gelohnt.
Danke für den Kommentar

Da stimme ich Ihnen völlig zu. Vor allem die Qualität der Fremd-Extensions ist z.T. erschreckend - deckt sich aber auch ziemlich mit der Qualität vieler Entwickler, die einen Magentoshop umsetzen - zumindest habe ich den Eindruck vom Großteil jener Shops, die von anderen Leuten umgesetzt wurden und wir dann später für bestimmte "Feuerwehr-Einsätze" engagiert wurden.

Auch Magento Core hat/hatte mMn lange Zeit viel zu viele Bugs. Die Qualität hat sich in den vergangenen Versionen zweifelsfrei verbessert. Die 2er Version darf sicher mit Spannung erwartet werden. Allerdings freue ich mich schon jetzt viel mehr auf die kommende Version von Drupal Commerce, das in Kombination mit der mächtigen Basis von Drupal 8 sicherlich neue Maßstäbe setzen wird und eine breite Basis von PHP-Entwicklern ansprechen wird, da der Kern von D8 wie viele andere PHP Frameworks auf Symfony2 Komponenten setzt und Commerce 2 sich selbst auch eine breitere Basis zurechtlegt. Grundlegende Dinge wie Adressierung, Umsatzsteuerregeln, Preisberechnung, Warenkorb, etc wurden Drupal-unabhängig als eigene Projekte auf Github veröffentlicht und werden z.T. auch bereits von anderen E-Commerce Systemen verwendet und dadurch auch qualitativ von mehreren Seiten verbessert.

Uli

vor 7 years 6 months

Entspricht auch meinen Erfahrungen
Das entspricht auch meinen Erfahrungen. Ich musste sogar noch einen größeren Versionssprung machen, von 1.4 auf 1.9. Alleine die automatische Migration der Datenbank auf dem Rootserver unseres Kunden hat mehrere Stunden gedauert und man hat während dessen keinerlei Fortschrittsinformationen bekommt. Ich stieß dabei auf verschiedene Probleme, wie z.B. dass die E-Mail Templates nun in der Datenbank gespeichert sind, dass das Passwort-zurücksetzen Formular geändert wurde, dass es auf einigen Adminseiten zu Fehlern kam, einige Module nicht mehr funktionierten, mehrere Templates angepasst werden mussten. und so weiter und so weiter. Nun ist ja schon Magento 2 draußen und das ist wieder völlig inkompatibel mit den Vorgängerversionen. Warum gibt es kein Open Source E-Commerce System, dass so einfach wie Wordpress upzudaten ist? Ich bin nicht gerade der größte Fan von Wordpress, aber die Updates sind dort noch am schmerzfreiesten von den großen CMS gelöst.