Przegląd:

To pytanie zostało pierwotnie zadane, a następnie zamknięte na StackOverflow . W meta stwierdziliśmy , że tutaj jest właściwe miejsce na to pytanie.

To pytanie jest pomocne, aby pomóc wielu osobom znaleźć właściwy sposób oszacowania ulepszeń Magento.

Pytanie:

Chcę wiedzieć, jak mierzysz czas potrzebny na aktualizację Magento? Myślę, że większość z was miała trudności z odpowiedzią na pytanie klienta: „Ile czasu zajmie aktualizacja mojego sklepu Magento?”

Zwykle klient musi usłyszeć tylko numer, np .: „Zajmie to X godzin i będzie kosztować Y dolców”.

Główna idea tego pytania dotyczy strony technicznej i tego, co sprawdzasz jako programista, aby dokonywać własnych obliczeń dla aktualizacji Magento.

Utworzyłem następną listę kontrolną, dla własnych obliczeń:

• Czy dotknięty jest rdzeń Magento?
• Czy dotknięty jest schemat Magento DB?
• Czy w bazie danych mamy niespójne dane?
• Ile niestandardowych rozszerzeń jest zainstalowanych w lokalnej i społecznościowej puli kodów?
• Czy niestandardowe rozszerzenie jest zgodne z najnowszą wersją Magento?
• Czy twórca kompozycji użył pliku local.xml do dyrektyw układu, czy po prostu skopiował pliki xml z podstawowego / domyślnego / układu do katalogu układu niestandardowego motywu?
• Czy mamy przestarzałe dyrektywy / metody blokowania w plikach xml układu?
• Czy opracowałem ten sklep Magento?

Czy uważasz, że czegoś mi brakuje, a jeśli tak, czy chciałbyś podzielić się ze mną i ze społecznością dodatkowe punkty na liście kontrolnej?

Oszacowanie uaktualnienia Magento to proces gromadzenia informacji o modyfikacjach zastosowanych w instalacji, którą zamierzasz zaktualizować, sprawdzania, czy te modyfikacje mogą powodować problem, a następnie oceny, ile czasu potrzeba na ich obejście.

Wszystkie modyfikacje można dosłownie podzielić na poza rdzeniem i wewnątrz rdzenia .

Modyfikacje poza rdzeniem to te, które nie zostaną zastąpione aktualizacją. Są to rozszerzenia innych firm , podstawowe pliki umieszczone w zasięgu lokalnym (app / code / local / Mage) i niestandardowy motyw .

Wewnętrzne modyfikacje są stosowane bezpośrednio w plikach podstawowych Magento (aplikacja / kod / rdzeń), plikach lokalizacyjnych (app / locale / en_US), szablonach podstawowych i niektórych rzeczach, takich jak skrypty javascript , biblioteki zewnętrzne, które rzadko są dostosowywane, należy jednak wziąć pod uwagę .

Modyfikacje poza rdzeniem

Rozszerzenia stron trzecich

Podczas aktualizacji głównym źródłem problemów są rozszerzenia innych firm. Co oznacza, że ​​więcej rozszerzeń masz więcej czasu na ich analizę.

Pierwszą rzeczą do sprawdzenia jest to, czy funkcjonalność zapewniana przez rozszerzenie nie jest jeszcze zaimplementowana w uaktualnianej wersji Magento. Na przykład niektóre rozszerzenia, takie jak Yoast_CanonicalUrl, Mxperts_CustomerAddressczy Fontis_Wysiwygbyły szeroko stosowane w Magento 1.3.xx i starszych, ale teraz są częścią podstawowej funkcjonalności Magento i już nie potrzebuje.

Dlatego dobrym pomysłem jest sprawdzenie (zapytaj klienta), czy naprawdę potrzebujesz wszystkich posiadanych rozszerzeń. Mogą istnieć pewne rozszerzenia, które zainstalowałeś, ale tak naprawdę nigdy nie używałeś. W tym momencie dobrze jest zrobić coś w rodzaju porządków.

Następnie ważną rzeczą do sprawdzenia jest zgodność każdego z pozostałych rozszerzeń z aktualizowaną wersją Magento. W przypadku, gdy niektóre rozszerzenia nie są kompatybilne i żadne podobne rozszerzenia nie są dostępne, będziesz miał trudność z utratą niektórych funkcji lub modyfikacją istniejących rozszerzeń, aby były kompatybilne.

Uwaga: Nie modyfikuj bezpośrednio rozszerzenia innej firmy, ale utwórz nowe rozszerzenie, które przedłuży nieaktualne rozszerzenie, a następnie ustawi zależność w pliku XML ładowania początkowego nowego rozszerzenia.

Po wykonaniu wszystkich tych czynności można przedstawić rzeczywistą analizę każdego z pozostałych rozszerzeń. Zawsze zaczyna się od sprawdzenia etc/config.xmlakt. Są 3 rzeczy, których należy szukać:

• Przepisywanie klas nie jest samo w sobie czystą techniką, ale w niektórych przypadkach nie ma innej możliwości. Więc jeśli zmieniona zapisana klasa została zmieniona w nowej wersji Magento, może to stanowić potencjalny problem.
• Aktualizacje układu prawdopodobnie nie spowodują problemu z aktualizacją, ale jeśli rozszerzenie odnosi się do bloku, który jest nieaktualny w nowszej wersji Magento, będziesz musiał to obejść.
• Aktualizacje SQL są wysoce niedocenianym źródłem problemów podczas aktualizacji. Problem występuje, gdy rozszerzenie innej firmy tworzy klucz obcy odnoszący się do jakiegoś pola w domyślnej tabeli Magento. W rezultacie pole to jest zablokowane przed modyfikacjami. A jeśli natywny skrypt instalacyjny spróbuje zaktualizować to pole, zakończy się niepowodzeniem po cichu. Następnie każdy następny skrypt instalacyjny odnoszący się do tego pola spowoduje awarię aktualizacji.

app / code / local / Mage

Po zakończeniu korzystania z rozszerzeń czas zajrzeć do app/code/local/Magekatalogu. Tutaj znajdziesz zmodyfikowane pliki podstawowe przeniesione do localzakresu. Każdy z nich z pewnością będzie cię kosztował trochę siwych włosów, ponieważ nigdy nie wiesz (jeśli to nie ty je tam umieściłeś), co tam zmodyfikowano iz jakiego powodu. Musisz więc porównać każde z nich z miejscem pochodzenia i przenieść dodatkową funkcjonalność do pliku korespondencyjnego nowej wersji.

Motyw niestandardowy

Ostatnią modyfikacją poza grą jest niestandardowy motyw. Może to nie wydawać się dużym problemem, ale w rzeczywistości jest to szara strefa. Podstawowy motyw Magento jest modyfikowany z wersji na wersję, a każdy niestandardowy motyw musi naśladować niektóre z tych modyfikacji. Niestety nie ma srebrnej kuli, która określałaby, czego szukać i co należy migrować. Po aktualizacji przygotuj się na poważne niespodzianki i drobne niedociągnięcia.

Modyfikacje wewnętrzne

W idealnym świecie nie ma ich. Ale kiedy dostaniesz instalację Magento po tym, jak została wykorzystana przez zewnętrznych deweloperów, którzy oferują wiele za tanie, możesz oczekiwać wszystkiego. Tak więc modyfikacje wewnętrzne to te, które zostaną nadpisane podczas procesu aktualizacji. W większości przypadków nie spowoduje to żadnych błędów, ale w rezultacie utracisz funkcjonalność dodaną w tak brutalny sposób.

Jedynym sposobem na wykrycie wewnętrznych modyfikacji jest porównanie wszystkich plików instalacji Magento z czystymi plikami tej samej wersji. Polecam to zrobić z git. Dlaczego? Po prostu dlatego, że ładnie obsłuży wszystkie znaki nowej linii i białe znaki.

Nawet jeśli Twoja instalacja Magento nie jest uruchomiona w programie git, nadal możesz skopiować pliki do osobnego katalogu, a następnie uruchomić git init. Następnie dokonaj wstępnego zatwierdzenia, skopiuj „czyste” pliki Magento i uruchom git status. Otrzymasz coś takiego:

Teraz w zależności od liczby zmodyfikowanych plików, które można uruchomić jednocześnie git diffdla każdego pliku lub całej partii. To daje kompleksowe odniesienie do wszystkich wprowadzonych modyfikacji. Jeśli masz wizualizację git, taką jak phpStorm, życie jest dla ciebie o wiele łatwiejsze:

Sugeruję, aby to zrobić git diff > changes.txt, zawsze będziesz mieć ręcznie listę modyfikacji.

Dysponując listą podstawowych modyfikacji, możesz oszacować, co trzeba przenieść do nowej wersji i ile czasu to zajmie.

Teraz chciałbym udzielić kilku porad dotyczących faktycznej aktualizacji. Ten proces jest dobrze udokumentowany, więc nie będę pisać, jakie polecenia uruchomić i gdzie kliknąć. Chcę jednak podkreślić kilka ważnych rzeczy:

• Zakładamy, że przeprowadzasz aktualizację w swoim środowisku programistycznym. Uruchomienie aktualizacji na serwerze produkcyjnym to samobójstwo.
• Nie pozwól im zmieniać niczego podczas produkcji. Umieść swoje Magento pod kontrolą wersji, a nawet tymczasowymi plikami blokującymi przed zapisem.
• Wyłącz wszystkie rozszerzenia innych firm, ale zwróć uwagę, które z nich były początkowo wyłączone, abyś ich później nie włączał.
• Sprawdź, czy na serwerze działa skrypt czyszczenia Magento. Inaczej obciąć wszystkie tabele zaczynając dataflow_*, log_*, report_*.
• Przywróć domyślny motyw dotyczący czasu aktualizacji.

Po zakończeniu skryptu aktualizacji:

• Odwoływanie się do changes.txtdokonanych przed migracją wszystkich wewnętrznych modyfikacji, które naprawdę są warte migracji.
• Migruj app/code/local/Magemodyfikacje znalezione przed aktualizacją.
• Po kolei włącz rozszerzenia zewnętrzne.
• Odłóż swój motyw i kompleksowo porównaj wynik z serwerem produkcyjnym.
• Wdrażaj do produkcji, gdy będziesz zadowolony z rezultatu.

Wniosek

Wiem, że wszystko to brzmi przerażająco, ale jeśli regularnie aktualizujesz, utrzymujesz rdzeń w czystości i instalujesz rozszerzenia tylko od zaufanych dostawców i tylko jeśli naprawdę ich potrzebujesz, nie napotkasz większości trudności opisanych w tym artykule. Dbaj o zdrowie swojego Magento EcoSystem, a otrzymasz nagrodę.

Post Scriptum

W bardzo skomplikowanych przypadkach warto zacząć od nowa od najnowszej instalacji najnowszego Magento i krok po kroku migrować motyw i funkcjonalność sklepu. To na pewno zajmie trochę czasu, ale w końcu będziesz miał zdrowy system Magento z pełną świadomością tego, co się dzieje.

Ogólnie rzecz biorąc, kod podstawowy nigdy nie powinien być dotykany podczas programowania. W Magento istnieje wiele mechanizmów pozwalających na obejście wszelkich problemów, nawet wewnętrznych błędów. To powiedziawszy, są też inne kwestie, na które należy zwrócić uwagę.

1. Czy jakiekolwiek moduły społecznościowe lub lokalne zastępują kod podstawowy (można go przeszukać w folderze modułów <rewrite>i jest to zła praktyka, ponieważ naprawdę powinni używać nieuciążliwego kodu, takiego jak zdarzenia)
2. Magento stara się zachować zgodność kodu z poprzednimi wersjami, ale czasami kod zmienia się znacząco ( można go znaleźć tutaj ), jeśli jest wiele niezgodnych z poprzednimi wersjami zmian, które mogą zwiększyć proces.
3. Czy łatwo / można powielić kod do środowiska programistycznego? jeśli tak, wystarczy uaktualnienie i przetestowanie.
4. Czy wymagana jest aktualizacja? Czy w nowej wersji są funkcje, bez których klient nie może wyjść? Wszelkie problemy z bezpieczeństwem (wiele razy Magento zapewnia również poprawki)

Jeśli chodzi o szablon, z wcześniejszych doświadczeń mogę powiedzieć, że ledwo się psuje, chyba że deweloper oszalał na temat kodowania szablonu (który i tak powinien być w blokach).

Oto kilka rzeczy, o których należy pamiętać:

• Sprawdź, czy kompozycja jest kompatybilna (sprawdź, czy w plikach szablonów jest obszerne kodowanie - czasami robią to młodsi programiści)
• Sprawdź, jak są przechowywane media (czy używają CDN itp.)
• Sprawdź, czy istnieją jakieś specjalne metody buforowania (APC Memcached itp.)

Jednym ze sposobów obsługi tego typu żądań klientów jest dokonanie oceny szacunkowej.

Oznacza to powiedzenie klientowi, że poświęcisz mu (płatny) czas, aby na niego spojrzeć, i zapewni mu dokładniejsze ramy czasowe / koszty wykonania projektu.

Obranie tej trasy przynosi korzyści zarówno Tobie, jak i klientowi.

Klient zwykle czuje się pewniej w swoich szacunkach i przestrzega twoich zaleceń, co z kolei przynosi korzyści, redukując ewentualny stres.

Ocena szacunkowa:

Rzeczywisty przegląd szacunków byłby następujący:

• Zrzuć bazę danych na żywo i zaimportuj ją na maszynie programistycznej
• Skopiuj pliki magento z ich maszyny na żywo na maszynę programistyczną
• Upewnij się, że wszystko jest w porządku i działa
• Spróbuj uaktualnienia i przeprowadź wstępne testy, aby zobaczyć, co może się zepsuć

Proces ten powinien zająć średnio dwie naliczone godziny i da ci bardzo potrzebny wgląd w obecny system.

Dokonaliśmy różnych aktualizacji Magento CE, najgorsze z 1.3 do 1.7, które zajęły nam prawie 4 pełne dni. Początkowy szacunek wynosił 1-2 dni. Wydaje mi się, że uaktualnienie z wersji 1.x do wersji 2.x będzie podobnie dużym przedsięwzięciem, a nawet jeśli podstawowy zespół zapewni narzędzia do migracji, rozpoczęcie od zera może być czystsze.

Chcę dodać jedną rzecz do doskonałych odpowiedzi podanych powyżej:

• Sprawdź, czy istnieje VCS i odpowiedni proces wdrażania.

Nie zrobię aktualizacji bez odpowiednich procesów i możliwości wycofania się, gdy pojawią się problemy (nawet więcej, jeśli wcześniej nie działałem na stronie). Około 90% klientów zwracających się do nas o aktualizację Magento (którzy wcześniej nie byli naszymi klientami) ma tylko środowisko na żywo bez testowania / testowania, w ogóle VCS.

Ważną kwestią jest integracja z innymi podmiotami. Jest to coś, czego możesz nie być w stanie dostrzec, patrząc na stronę - klienci często mają systemy zaplecza pobierające zamówienia na przykład za pośrednictwem interfejsu API Magento, a jeśli nie poradzisz sobie z ciągłością tej integracji podczas aktualizacji wpaść w bałagan.

Podczas przeglądania komponentów uważaj na te, które komunikują się z innymi systemami - każdy z nich będzie włochaty do przetestowania, ponieważ nie chcesz przypadkowo wypchnąć danych testowych do działającego systemu. Często istnieje testowy punkt końcowy, który był używany przez pierwotnych programistów, ale możesz nie mieć już tych informacji podczas aktualizacji.