Hack łatki lub rdzenia

Kiedy pracuję nad projektem aktualizacji systemu, jedną z rzeczy, które robię, jest różnicowanie systemu klienta w stosunku do nowej instalacji Magento. Szukam podstawowych hacków lub dodatkowych plików, które nie są częścią standardowego Magento, aby upewnić się, że złapię jakąkolwiek podejrzaną, ale biznesową pracę wykonaną przez poprzedniego freelancera, kontrahenta, konsultanta lub agencję.

Jedną rzeczą, która zawsze mnie zaskakuje, są łatki. Przez lata Magento wydawało łatki „między wersjami” - zwykle w celu naprawy poprawki bezpieczeństwa lub zmiany interfejsu API dostawcy wysyłki / płatności.

Problem polega na tym, że z punktu widzenia diff łatki są nie do odróżnienia od podstawowych hacków - szczególnie gdy nie wiesz, które łaty (jeśli w ogóle) zostały zastosowane w systemie.

Co prowadzi do mojego pytania.

Jak odróżnić hack rdzenia od łaty?

Łaty Magento dostarczone przez wsparcie dołączą pewnego rodzaju log do app/etc/applied.patches.list. Nie wiem, kiedy i jak długo „skrypty” łatek to robią. Wydaje się, że łatki CE też to robią.

Jest to coś, z czym często sobie radzę (i nad tym teraz pracuję) i niestety, jak dotąd, jest to całkowicie ręczny proces - mamy zautomatyzowany proces, który oznacza każdy plik, który może zostać zmodyfikowany w ramach naszego pierwszego automatycznego audytu dla nowy klient wsparcia. Mamy wtedy kogoś, kto różnicuje te pliki i wykluczamy wszelkie oczywiste fałszywe alarmy (tj. Zmiany białych znaków).

Następnie część zabawy - starszy członek naszego zespołu, który od dłuższego czasu pracuje z Magento, musi przyjrzeć się wynikom, aby ustalić, czy którykolwiek ze zmodyfikowanych plików może być wynikiem poprawki. Przyjrzeliśmy się aktualizacji naszego systemu, aby sprawdzić wszystkie łaty, o których wiemy / że możemy dostać się w swoje ręce, i może to działać w CE, ale w EE jest to jeszcze trudniejsze, ponieważ wsparcie EE czasami wydaje łaty bezpośrednio dla klientów, którzy nigdy nie są wypuszczani w żaden inny sposób ani nie są katalogowani w spójny sposób.

Tak więc, kiedy przeprowadzamy ten poziom przeglądu, polegamy na wcześniejszych doświadczeniach w stosowaniu tych poprawek + zdrowy rozsądek (tj. Czy jest to tylko zmiana punktu końcowego interfejsu API? Jeśli tak, to czy ten zmieniony punkt końcowy jest obecny w zaktualizowanej wersji? Jeśli tak, to była łatka i można ją zignorować).

Teoretycznie proste byłoby nałożenie wszystkich łat dostępnych na stronie pobierania CE itp. Na każdą odpowiednią wersję CE i porównanie z nimi (FYI, nie używamy diff dla pierwszego przejścia - używamy haszowania, w po części dlatego, że wbudowaliśmy tę technologię w narzędzie, które może zdalnie sprawdzać witrynę bez konieczności jej wcześniejszego pobierania). Wykluczałoby to większość poprawek, ale nadal nie pomaga w przypadku łatek CE lub EE, które nie są publikowane w publicznym obszarze pobierania dla CE lub w klienckim / chronionym obszarze pobierania dla EE. Wymagałoby to od Magento wprowadzenia spójnej polityki, aby WSZYSTKIE łaty były udostępniane WSZYSTKIM klientom, i wysyłania ich tam, gdzie moglibyśmy do nich dotrzeć.

Tak więc nie sądzę, że istnieje sposób na 100% zautomatyzowanie tego, dopóki nie nastąpią zmiany po stronie Magento, niestety.

Jednym ze sposobów, w jaki podszedłem do tego, gdy robiłem wiele aktualizacji i starałem się usystematyzować proces, było faktyczne zatwierdzenie łatek bezpośrednio do głównego repozytorium kodu, przeciwko któremu używasz różnic.

To faktycznie ma dwie zalety:

1. Nigdy więcej fałszywych trafień pojawiających się w twoich różnicach.

2. Załóżmy, że masz witrynę, która nie ma określonej poprawki. Możesz powiedzieć, że jest to problem, ponieważ pojawi się jako brakujący kod w twoim pliku różnicowym, chociaż technicznie niczego nie brakuje w porównaniu do świeżego niepakowanego pobrania. Ale faktem, że brakuje im łaty, jest problem, który należy rozwiązać - więc idealnie, że pojawia się ona w twoim pliku różnicowym, abyś mógł ją naprawić wraz z aktualizacją.

Nie sądzę, aby posiadanie Magento w repozytorium projektu było początkowo dobrym pomysłem na wypadek, gdybyś zarządzał więcej niż 2-3 klientami. Ponieważ zawsze łatwiej jest popsuć zastosowane łaty systemowe hackami rdzenia.

Moim zdaniem najlepszą opcją jest posiadanie lustrzanego repozytorium repozytorium Magento ze znacznikami wersji, które wskazują na konkretną wersję Magento z możliwymi oficjalnymi łatkami.

Ułatwiłoby to także utrzymanie własnych łat do plików, takich jak Mage_Core_Model_Config dla mocno obciążonych stron internetowych i niektórych innych, poprzez wprowadzenie ich za pośrednictwem kompozytora o numerze wersji pasującym do twojej wersji Magento.

Tak więc w tym przypadku uaktualnienie wszystkich projektów klienta do poprawionego kodu Magento spowoduje tylko wzrost wersji pliku kompozytora. Również trzymanie kodu projektu poza rdzeniem zmusi deweloperów do nie rąbania rdzenia.

Jeśli chodzi o definicję łaty i hacka, wolałbym to tak nazwać:

1. Zmiana oryginalnego pliku podstawowego przez oficjalny plik łaty - jest to łatka
2. Zmiana oryginalnego pliku podstawowego przez twój zespół - jest to włamanie.
3. Zmiana lokalnego skopiowanego pliku podstawowego w celu naprawy błędu - jest to łatka
4. Zmiana lokalnego skopiowanego pliku podstawowego w celu zapewnienia nowej funkcjonalności - jest to włamanie

Przenosząc rdzeń do oddzielnego repozytorium, upewnisz się, że masz tylko łataną wersję zgodnie z pozycją 1. I możesz łatwo zainstalować własne łatki nad kompozytorem w lokalnej puli kodów, więc masz wszystko zgodnie z punktem 3. W przypadku 2 i 4 możesz utworzyć zaczepkę git commit w repozytorium projektu, aby zakazać jakiegokolwiek zatwierdzania kodu w tym katalogu.

Patrzę na plik zastosowanych łat w tym /app/etc/folderze i pracuję wstecz. Ale jak dowiedziałem się z aktualizacji, mogę po prostu usunąć plik w wersji, w której znajduje się załatany plik, a przy następnej łatce jest czysty.

Cokolwiek z Magento nazwałbym łatką. Cała reszta to hack.