Patch oder Core Hack

Wenn ich ein System-Upgrade-Projekt durchführe, besteht eine meiner Aufgaben darin, das System eines Clients von einer neuen Magento-Installation zu unterscheiden. Ich suche nach Core-Hacks oder zusätzlichen Dateien, die nicht zum Standard von Magento gehören, um sicherzustellen, dass ich alle geschäftskritischen Arbeiten eines früheren Freiberuflers, Auftragnehmers, Beraters oder einer Agentur abfange.

Eine Sache, die mich jedoch immer überrumpelt, sind Flecken. Im Laufe der Jahre hat Magento "Zwischenversions" -Patches herausgegeben - in der Regel zur Behebung von Sicherheitslücken oder zur Änderung der API eines Versand- / Zahlungsanbieters.

Das Problem ist, dass Patches aus der Sicht eines Diffs nicht von Core-Hacks zu unterscheiden sind - insbesondere, wenn Sie nicht wissen, welche Patches (falls vorhanden) auf das System angewendet wurden.

Was zu meiner Frage führt.

Wie unterscheidet man einen Core-Hack von einem Patch?

Von der Unterstützung bereitgestellte Magento-Patches hängen eine Art Protokoll an app/etc/applied.patches.list. Ich weiß nicht, wann oder wie lange die Patch "Skripte" dies getan haben. Dies scheinen auch die CE-Patches zu tun.

Dies ist etwas, mit dem ich mich oft beschäftige (und an dem ich gerade arbeite), und leider handelt es sich bislang um einen vollständig manuellen Prozess - wir haben einen automatisierten Prozess, der jede Datei kennzeichnet, die im Rahmen unserer anfänglichen automatisierten Prüfung für geändert werden könnte ein neuer Support-Client. Wir haben dann jemanden, der diese Dateien vergleicht und alle offensichtlichen Fehlalarme (z. B. Leerraumänderungen) ausschließt.

Dann muss der unterhaltsame Teil - ein hochrangiges Mitglied unseres Teams, das seit einiger Zeit mit Magento zusammenarbeitet, anhand der Ergebnisse feststellen, ob eine der geänderten Dateien das Ergebnis eines Patches sein könnte. Wir haben uns überlegt, unser System zu aktualisieren, um zu prüfen, ob alle uns bekannten Patches verfügbar sind, und das könnte für CE funktionieren, aber für EE ist es noch schwieriger, da die EE-Unterstützung manchmal Patches direkt herausgibt an Kunden, die niemals auf andere Weise veröffentlicht oder auf konsistente Weise katalogisiert werden.

Wenn wir diese Überprüfungsstufe durchführen, stützen wir uns auf frühere Erfahrungen mit der Anwendung dieser Patches und dem gesunden Menschenverstand (dh handelt es sich nur um eine Änderung des Endpunkts einer API? Wenn ja, ist dieser geänderte Endpunkt in der aktualisierten Version vorhanden? Wenn ja, es war ein Patch und kann ignoriert werden).

Es wäre theoretisch einfach, alle auf der CE - Download - Seite usw. verfügbaren Patches auf jede zutreffende CE - Version anzuwenden und mit diesen zu vergleichen Dies ist zum Teil darauf zurückzuführen, dass wir diese Technologie in ein Tool eingebaut haben, mit dem eine Site aus der Ferne überprüft werden kann, ohne sie zuerst herunterladen zu müssen. Das würde einen Großteil der Patches ausschließen, aber es hilft immer noch nichts für CE- oder EE-Patches, die nicht im öffentlichen Downloadbereich für CE oder im Client- / geschützten Downloadbereich für EE veröffentlicht wurden. Dazu müsste Magento eine konsistente Richtlinie erstellen, mit der ALLE Patches ALLEN Kunden zur Verfügung gestellt werden und die dort veröffentlicht werden, wo wir sie erreichen können.

Daher gibt es meiner Meinung nach leider keinen Weg, dies zu 100% zu automatisieren, bis Änderungen auf der Magento-Seite eintreten.

Eine Möglichkeit, wie ich dies angegangen bin, als ich viele Upgrades durchgeführt und versucht habe, den Prozess zu systematisieren, bestand darin, die Patches direkt in Ihr Kern-Code-Repository zu übertragen, gegen das Sie sich wehren möchten.

Dies hat tatsächlich zwei Vorteile:

1. Keine Fehlalarme mehr in Ihren Diffs.

2. Angenommen, Sie haben eine Site, auf der es keinen bestimmten Patch gibt. Sie könnten sagen, dass dies ein Problem ist, da es als fehlender Code in Ihrem Diff angezeigt wird, obwohl technisch gesehen nichts fehlt, im Vergleich zu einem frischen, nicht gepatchten Download. Tatsächlich ist das Fehlen eines Patches jedoch ein Problem, das behoben werden sollte. Daher ist es perfekt, dass es in Ihrem Diff angezeigt wird, damit Sie es zusammen mit dem Upgrade beheben können.

Ich denke nicht, dass es am Anfang eine gute Idee ist, ein Magento in Ihrem Projekt-Repo zu haben, falls Sie mehr als 2-3 Clients verwalten. Da es immer einfacher ist, angewendete System-Patches mit Core-Hacks zu verwechseln.

Meiner Meinung nach ist die beste Option, einen Composer-Magento-Repository-Spiegel mit Versions-Tags zu haben, die auf eine bestimmte Magento-Version mit möglichen offiziellen Patches verweisen.

Außerdem können Sie Ihre eigenen Patches für Dateien wie Mage_Core_Model_Config für hochgeladene Websites und einige andere einfacher verwalten, indem Sie deren Installation über Composer mit einer Versionsnummer einführen, die Ihrer Magento-Installation entspricht.

In diesem Fall führt Ihr Upgrade aller Kundenprojekte auf einen gepatchten Magento-Code nur zu einer Versionserhöhung Ihrer Composer-Datei. Wenn Sie außerdem den Projektcode vom Kern trennen, werden Ihre Entwickler gezwungen, den Kern nicht zu hacken.

Was die Definition von Patch und Hack angeht, würde ich es am liebsten so nennen:

1. Eine Änderung der ursprünglichen Kerndatei durch die offizielle Patch-Datei - es handelt sich um einen Patch
2. Eine Änderung in der ursprünglichen Kerndatei durch Ihr Team - es ist ein Hack.
3. Eine Änderung in der lokal kopierten Core-Datei zum Zweck der Fehlerbehebung - es ist ein Patch
4. Eine Änderung in der lokal kopierten Core-Datei, um neue Funktionen bereitzustellen - es ist ein Hack

Wenn Sie also core in ein separates Repo verschieben, stellen Sie sicher, dass Sie nur die Version gemäß Punkt 1 gepatcht haben. Und Sie können problemlos Ihre eigenen Patches über composer in den lokalen Code-Pool installieren, sodass Sie alles gemäß Punkt 3 haben und 4 Sie können einen Git-Commit-Hook in Project Repo erstellen, um jegliches Code-Commit in dieses Verzeichnis zu verhindern.

Ich schaue auf die Datei mit den angewendeten Patches in diesem /app/etc/Ordner und arbeite rückwärts. Aber wie ich aus dem Upgrade gelernt habe, kann ich die Datei nur in einer Version löschen, in der die gepatchte Datei enthalten ist, und beim nächsten Mal ist sie sauber.

Alles von Magento würde ich als Patch bezeichnen. Alles andere ist ein Hack.