Überblick:

Diese Frage wurde ursprünglich gestellt und später bei StackOverflow geschlossen . Wir haben in meta angegeben , dass hier der richtige Ort für diese Frage ist.

Diese Frage soll vielen helfen, den richtigen Weg zu finden, um die Magento-Upgrades einzuschätzen.

Die Frage:

Ich bin interessiert zu wissen, wie Sie die benötigte Zeit für ein Magento-Upgrade messen. Ich vermute, dass die meisten von Ihnen Schwierigkeiten hatten, die Frage des Kunden zu beantworten: "Wie lange wird es dauern, mein Magento-Geschäft zu aktualisieren?"

Normalerweise muss der Kunde nur eine Nummer hören, zum Beispiel: "Es dauert X Stunden und kostet Y Dollar."

Die Hauptidee hinter der Frage ist die technische Seite und was überprüfen Sie als Entwickler, um Ihre eigenen Berechnungen für Magento-Upgrades durchzuführen.

Ich habe die nächste Checkliste nur für meine eigenen Berechnungen erstellt:

• Ist der Magento-Kern berührt?
• Ist das Magento DB-Schema betroffen?
• Haben wir inkonsistente Daten in der DB?
• Wie viele benutzerdefinierte Erweiterungen sind im lokalen und Community-Code-Pool installiert?
• Sind die benutzerdefinierten Erweiterungen mit der neuesten Version von Magento kompatibel?
• Hat der Theme-Entwickler die Datei local.xml für die Layout-Anweisungen verwendet oder nur XML-Dateien aus dem Basis- / Standard- / Layout-Verzeichnis in das Layout-Verzeichnis des benutzerdefinierten Themas kopiert?
• Haben wir veraltete Layout-Direktiven / Block-Methoden in den Layout-XML-Dateien?
• Habe ich diesen Magento-Shop entwickelt?

Denken Sie, dass mir etwas fehlt und wenn ja, möchten Sie mir und der Community Ihre zusätzlichen Punkte für die Checkliste mitteilen?

Beim Schätzen des Magento-Upgrades werden Informationen zu den Änderungen erfasst, die an der zu aktualisierenden Installation vorgenommen wurden. Anschließend wird geprüft, ob diese Änderungen ein Problem verursachen können, und es wird bewertet, wie viel Zeit erforderlich ist, um sie zu umgehen.

Alle Modifikationen können buchstäblich in Off-Core- und In-Core- Modifikationen unterteilt werden .

Off-Core-Modifikationen sind solche, die beim Upgrade nicht überschrieben werden. Dies sind Erweiterungen von Drittanbietern , Kerndateien, die in den lokalen Bereich (app / code / local / Mage) gestellt werden, und ein benutzerdefiniertes Thema .

In-Core-Änderungen werden direkt auf Magento- Core-Dateien (app / code / core), Lokalisierungsdateien (app / locale / en_US), Core-Vorlagen und einige Dinge wie Javascripts angewendet , externe Bibliotheken, die selten angepasst werden, müssen dennoch berücksichtigt werden .

Off-Core-Modifikationen

Erweiterungen von Drittanbietern

Bei Upgrades treten hauptsächlich Probleme mit Erweiterungen von Drittanbietern auf. Je mehr Erweiterungen Sie haben, desto mehr Zeit benötigen Sie, um sie zu analysieren.

Als Erstes müssen Sie überprüfen, ob die von der Erweiterung bereitgestellten Funktionen in einer Magento-Version, auf die Sie aktualisieren, noch nicht implementiert sind. Zum Beispiel einiger Erweiterungen wie Yoast_CanonicalUrl, Mxperts_CustomerAddressoder Fontis_Wysiwygwurden in Magento 1.3.xx und älter , aber jetzt sind Teil des Kerns Magento Funktionalität und nicht mehr benötigt werden weit verbreitet.

Dann ist es eine gute Idee, zu überprüfen (fragen Sie Ihren Kunden), ob Sie wirklich alle diese Erweiterungen benötigen, die Sie haben. Möglicherweise haben Sie einige Erweiterungen installiert, aber nie wirklich verwendet. An diesem Punkt ist es also gut, eine Art Bereinigung vorzunehmen.

Dann ist es wichtig, die Kompatibilität aller verbleibenden Erweiterungen mit einer Magento-Version zu überprüfen, auf die Sie aktualisieren. Falls einige Erweiterungen nicht kompatibel sind und keine ähnlichen Erweiterungen verfügbar sind, haben Sie eine schwierige Wahl, entweder einige Funktionen zu verlieren oder vorhandene Erweiterungen zu ändern, um sie kompatibel zu machen.

Hinweis: Ändern Sie Erweiterungen von Drittanbietern nicht direkt, sondern erstellen Sie eine neue Erweiterung, durch die eine veraltete Erweiterung erweitert wird, und legen Sie dann eine Abhängigkeit in einem Bootstrap-XML der neuen Erweiterung fest.

Anschließend kann die tatsächliche Analyse der verbleibenden Erweiterungen bereitgestellt werden. Sie beginnt immer mit der etc/config.xmlAkteneinsicht. Es gibt 3 Dinge zu suchen:

• Das Umschreiben von Klassen ist an sich keine saubere Technik, aber in einigen Fällen gibt es keinen anderen Weg. Wenn also eine umgeschriebene Klasse in der neuen Version von Magento geändert wurde, könnte dies ein potenzielles Problem sein.
• Layout-Updates verursachen mit geringerer Wahrscheinlichkeit ein Problem mit Ihrem Upgrade. Wenn die Erweiterung jedoch auf einen Block verweist, der in einer neueren Magento-Version veraltet ist, müssen Sie dies umgehen.
• SQL-Updates sind eine stark unterschätzte Ursache für Probleme bei Upgrades. Das Problem tritt auf, wenn eine Drittanbietererweiterung einen Fremdschlüssel erstellt, der auf ein Feld in der Standard-Magento-Tabelle verweist. Infolgedessen ist dieses Feld für Änderungen gesperrt. Wenn dann das native Installationsskript versucht, dieses Feld zu aktualisieren, schlägt dies unbemerkt fehl. Danach stürzt jedes nächste Installationsskript, das auf dieses Feld verweist, Ihr Upgrade ab.

app / code / local / Mage

Nachdem Sie mit Ihren Erweiterungen fertig sind, ist es Zeit, sich Ihr app/code/local/MageVerzeichnis anzusehen . Hier finden Sie modifizierte Core-Dateien, die in einen localBereich verschoben wurden . Jeder von ihnen wird Sie sicherlich einige graue Haare kosten, weil Sie nie wissen (wenn Sie es nicht waren, der sie dort abgelegt hat), was dort geändert wurde und aus welchem ​​Grund. Sie müssen also jedes mit einem Ursprung vergleichen und die hinzugefügte Funktionalität in die entsprechende Datei der neuen Version migrieren.

Benutzerdefiniertes Thema

Die letzte Änderung außerhalb des Kerns ist das benutzerdefinierte Thema. Dies scheint keine große Sache zu sein, aber tatsächlich ist dies eine Grauzone. Das Magento-Basisthema wird von Version zu Version geändert, und jedes benutzerdefinierte Thema muss einige dieser Änderungen imitieren. Leider gibt es kein Patentrezept, um zu bestimmen, wonach gesucht und was migriert werden muss. Seien Sie also nach dem Upgrade auf einige große Überraschungen und ein paar Kleinigkeiten gefasst.

In-Core-Modifikationen

In der perfekten Welt gibt es keine. Aber wenn Sie eine Magento-Installation haben, nachdem sie von Drittanbietern missbraucht wurde, die viel für wenig Geld anbieten, können Sie mit allem rechnen. In-Core-Änderungen sind also solche, die während des Aktualisierungsprozesses überschrieben werden. In den meisten Fällen wird es keine Fehler geben, aber infolgedessen verlieren Sie die Funktionalität, die auf solch brutale Weise hinzugefügt wurde.

Die einzige Möglichkeit, Änderungen im Kern zu erkennen, besteht darin, alle Dateien Ihrer Magento-Installation mit sauberen Dateien derselben Version zu vergleichen. Ich empfehle es mit git zu machen. Warum? Einfach, weil es alle Zeilenumbrüche und Leerzeichen gut handhabt.

Auch wenn Ihre Magento-Installation nicht unter git ausgeführt wird, können Sie Ihre Dateien in ein separates Verzeichnis kopieren und dann git init ausführen. Führen Sie dann das erste Commit durch, kopieren Sie die "sauberen" Magento-Dateien und führen Sie sie aus git status. Sie erhalten so etwas:

Abhängig von der Anzahl der geänderten Dateien können Sie jetzt git diffjede Datei oder den gesamten Stapel gleichzeitig ausführen . Auf diese Weise erhalten Sie einen umfassenden Überblick über alle vorgenommenen Änderungen im Kern. Wenn Sie eine Git-Visualisierung wie phpStorm haben, ist das Leben für Sie viel einfacher:

Ich schlage vor, git diff > changes.txtSie haben immer eine Liste der Änderungen von Hand.

Mit der Liste der wichtigsten Änderungen können Sie abschätzen, was in eine neue Version übertragen werden muss und wie viel Zeit dafür erforderlich ist.

Jetzt möchte ich einige Ratschläge für ein tatsächliches Upgrade geben. Dieser Vorgang ist gut dokumentiert, sodass ich nicht schreibe, welche Befehle ausgeführt werden sollen und auf welche Stelle geklickt werden soll. Ich möchte jedoch einige wichtige Dinge hervorheben:

• Wir gehen davon aus, dass Sie ein Upgrade in Ihrer Entwicklungsumgebung durchführen. Ein Upgrade auf Ihrem Produktionsserver ist Selbstmord.
• Lassen Sie sie während des Upgrades nichts an der Produktion ändern. Versetzen Sie Ihren Magento unter Versionskontrolle oder sperren Sie sogar temporäre Dateien vor dem Schreiben.
• Deaktivieren Sie alle Nebenstellen von Drittanbietern, beachten Sie jedoch, welche ursprünglich deaktiviert waren, damit Sie sie später nicht aktivieren können.
• Überprüfen Sie, ob auf dem Server ein Magento-Bereinigungsskript ausgeführt wird. Gestutzt sonst alle Tabellen , beginnend mit dataflow_*, log_*, report_*.
• Beim Upgrade auf das Standarddesign zurücksetzen.

Nach Abschluss des Upgrade-Skripts:

• Wenn changes.txtSie auf die vor der Migration vorgenommenen Änderungen verweisen, werden alle wichtigen Änderungen migriert, die wirklich migriert werden müssen.
• Migrieren app/code/local/MageSie die vor dem Upgrade gefundenen Änderungen.
• Nacheinander aktivieren Sie Erweiterungen von Drittanbietern.
• Setzen Sie Ihr Thema zurück und vergleichen Sie das Ergebnis umfassend mit dem Produktionsserver.
• Stellen Sie die Produktion ein, sobald Sie mit dem Ergebnis zufrieden sind.

Fazit

Ich weiß, das hört sich alles beängstigend an, aber wenn Sie regelmäßig ein Upgrade durchführen, Ihren Kern sauber halten und Erweiterungen nur von Anbietern installieren, denen Sie wirklich vertrauen, und nur, wenn Sie sie wirklich benötigen, werden Sie den meisten in diesem Artikel beschriebenen Schwierigkeiten nicht begegnen. Halten Sie Ihr Magento EcoSystem gesund und Sie werden belohnt.

Post Scriptum

In sehr komplizierten Fällen ist es sinnvoll, mit einer Neuinstallation von Magento von vorne zu beginnen und das Thema und die Funktionen Ihres Shops Schritt für Schritt zu migrieren. Dies wird definitiv einige Zeit in Anspruch nehmen, aber am Ende werden Sie ein gesundes Magento-System haben, das genau weiß, was vor sich geht.

Im Allgemeinen sollte der Kerncode während der Entwicklung niemals berührt werden. Es gibt viele Mechanismen in Magento, mit denen Sie Probleme, auch interne Fehler, umgehen können. Davon abgesehen gibt es noch andere Punkte, auf die man achten muss.

1. Überschreiben Community- oder lokale Module den Kerncode? (Kann im Modulordner nach gesucht werden <rewrite>, und es ist eine schlechte Praxis, da sie eigentlich nicht aufdringlichen Code wie Ereignisse verwenden sollten.)
2. Magento versucht, den Code abwärtskompatibel zu halten, aber manchmal ändert sich der Code erheblich ( hier zu finden ), wenn es viele inkompatible Änderungen gibt, die den Prozess möglicherweise ergänzen.
3. Ist es einfach / möglich, den Code in eine Entwicklungsumgebung zu duplizieren? Wenn dies der Fall ist, müssen Sie möglicherweise nur das Upgrade ausführen und testen.
4. Wird das Upgrade benötigt? Gibt es Funktionen in der neuen Version, auf die der Client nicht verzichten kann? Alle Sicherheitsprobleme (oft stellt Magento auch Back-Patches bereit)

Was die Vorlage betrifft, kann ich Ihnen aus früheren Erfahrungen sagen, dass sie kaum kaputt geht, es sei denn, der Entwickler hat die Vorlagencodierung verrückt gemacht (die sowieso in Blöcken sein sollte).

Hier sind einige Dinge zu beachten:

• Überprüfen Sie, ob das Design kompatibel ist (überprüfen Sie, ob die Vorlagendateien umfangreiche Codierungen enthalten - manchmal tun dies Junior-Entwickler).
• Überprüfen Sie, wie die Medien gespeichert werden (verwenden sie CDNs usw.)
• Überprüfen Sie, ob spezielle Caching-Methoden vorhanden sind (APC Memcached usw.).

Eine Möglichkeit, diese Art von Kundenanfragen zu bearbeiten, besteht darin, eine Schätzung vorzunehmen.

Dies beinhaltet, dem Kunden mitzuteilen, dass Sie etwas (abrechnungsfähige) Zeit damit verbringen, sich damit zu befassen, und ihnen einen genaueren Zeitrahmen / Kostenrahmen für die Durchführung des Projekts zu geben.

Wenn Sie diesen Weg gehen, profitieren Sie und der Kunde.

Der Kunde fühlt sich in der Regel sicherer in Ihre Einschätzung und respektiert Ihre Empfehlungen, die Ihnen wiederum zugute kommen, indem sie mögliche Belastungen reduzieren.

Bewertung abschätzen:

Die eigentliche Überprüfung der Schätzung würde ungefähr so ​​aussehen:

• Sichern Sie die Live-Datenbank und importieren Sie sie auf einem Entwicklungscomputer
• Kopieren Sie die Magento-Dateien von ihrer Live-Maschine auf Ihre Entwicklungsmaschine
• Stellen Sie sicher, dass alles in Ordnung ist und funktioniert
• Versuchen Sie das Upgrade und führen Sie einige erste Tests durch, um festzustellen, was möglicherweise nicht funktioniert

Dieser Vorgang sollte durchschnittlich zwei Stunden in Anspruch nehmen und Ihnen einen wichtigen Einblick in das jeweilige System geben.

Wir haben verschiedene Upgrades auf Magento CE durchgeführt, wobei das schlimmste von 1.3 auf 1.7 war, was uns fast 4 volle Tage gekostet hat. Die anfängliche Schätzung betrug 1-2 Tage. Ich denke, dass ein Upgrade von 1.x auf 2.x ein ähnlich großes Unterfangen sein wird, und selbst wenn Migrationstools vom Kernteam bereitgestellt werden, könnte es sauberer sein, einfach von vorne zu beginnen.

Ich möchte eine Sache zu den hervorragenden Antworten hinzufügen:

• Überprüfen Sie, ob ein VCS und ein ordnungsgemäßer Bereitstellungsprozess vorhanden sind.

Ich werde kein Upgrade durchführen, ohne die richtigen Prozesse und die Möglichkeit, bei Problemen einen Schritt zurückzutreten (noch mehr, wenn ich vorher nicht an der Site gearbeitet habe). Ungefähr 90% der Kunden, die sich wegen eines Magento-Upgrades an uns wenden (was bisher noch nicht unsere Kunden waren), verfügen nur über eine Live-Umgebung ohne jegliche Tests / Staging-Funktionen, unabhängig davon, ob VCS installiert ist.

Die Integration mit anderen Entitäten ist eine wichtige Frage. Dies ist etwas, das Sie auf der Website möglicherweise nicht erkennen können. Kunden haben zum Beispiel häufig Back-End-Systeme, die Bestellungen über die Magento-API abrufen, und wenn Sie die Kontinuität dieser Integration während des Upgrades nicht bewältigen kann in ein Chaos geraten.

Achten Sie bei der Überprüfung von Komponenten auf Komponenten, die mit anderen Systemen kommunizieren. Jeder Test wird schwierig, da Sie die Testdaten nicht versehentlich auf ein Live-System übertragen möchten. Häufig gibt es einen Testendpunkt, der von den ursprünglichen Entwicklern verwendet wurde. Möglicherweise verfügen Sie jedoch beim Upgrade nicht mehr über diese Informationen.