Aktualizacja Laravel i PHP
Podnosimy stare aplikacje w Laravelu i PHP do wspieranych wersji — krok po kroku, z testami, które pilnują, że po aktualizacji wszystko działa jak wcześniej.
Aplikacja w Laravelu napisana kilka lat temu zwykle działa — i właśnie dlatego nikt jej nie aktualizuje. Z czasem wersja PHP i frameworka wypada ze wsparcia, przestają przychodzić poprawki bezpieczeństwa, hosting przestaje oferować starą wersję PHP, a nowe biblioteki nie chcą się zainstalować. Każdy kolejny rok zwłoki podnosi koszt aktualizacji.
Kiedy aktualizacja jest pilna
- aplikacja działa na PHP 7.x albo starszym Laravelu, które nie dostają już poprawek bezpieczeństwa,
- dostawca serwera zapowiada wyłączenie starej wersji PHP,
- nie da się dodać nowej biblioteki albo integracji, bo wymaga nowszego frameworka,
- audyt bezpieczeństwa albo klient wymaga wspieranych wersji oprogramowania.
Jak przeprowadzamy aktualizację
1. Inwentaryzacja
Sprawdzamy wersje PHP, Laravela i wszystkich pakietów, szukamy pakietów porzuconych przez autorów i miejsc, w których kod korzysta z funkcji usuniętych w nowszych wersjach. Na tej podstawie powstaje plan i estymacja.
2. Siatka bezpieczeństwa
Zanim cokolwiek zmienimy, dopisujemy testy dla najważniejszych ścieżek: logowania, płatności, kluczowych procesów biznesowych. To one mówią, czy po aktualizacji aplikacja działa tak samo jak przed nią.
3. Aktualizacja wersja po wersji
Laravel podnosimy stopniowo, wersja po wersji, zgodnie z oficjalnymi przewodnikami aktualizacji, a PHP równolegle do kolejnych wydań. Powtarzalne zmiany w kodzie wykonujemy narzędziami do automatycznego refaktoringu, a resztę ręcznie. Porzucone pakiety wymieniamy na utrzymywane odpowiedniki albo własny kod.
4. Frontend i infrastruktura
Przy okazji porządkujemy budowanie frontendu (np. przejście z Laravel Mix na Vite) i środowisko uruchomieniowe — obraz Dockera z nową wersją PHP, konfigurację serwera i pipeline CI.
5. Wdrożenie bez niespodzianek
Nową wersję sprawdzamy na środowisku testowym z kopią danych, a wdrożenie planujemy tak, żeby w razie problemu dało się szybko wrócić do poprzedniej.
Po aktualizacji
Żeby za kilka lat nie wracać do tego samego problemu, proponujemy regularne, małe aktualizacje w ramach utrzymania aplikacji. Podniesienie o jedną wersję co roku kosztuje ułamek skoku o kilka wersji naraz. Jeśli aplikację pisał ktoś inny, zaczynamy od audytu. Więcej o tym, jak pracujemy z tym frameworkiem, na stronie Laravel.
Najczęściej zadawane pytania
Czy da się przeskoczyć od razu kilka wersji Laravela?
Da się, ale bezpieczniej jest przechodzić wersja po wersji. Każdy krok ma własny przewodnik zmian, a testy po każdym kroku pokazują, co przestało działać. Całość i tak trafia na produkcję jednym wdrożeniem.
Aplikacja nie ma testów. Czy to problem?
To częsta sytuacja. Przed aktualizacją dopisujemy testy dla najważniejszych ścieżek, żeby mieć pewność, że po zmianach działają tak samo. Te testy zostają w projekcie i przydają się przy kolejnych zmianach.
Czy aplikacja będzie niedostępna podczas aktualizacji?
Prace prowadzimy na osobnej gałęzi i środowisku testowym, więc produkcja działa normalnie. Samo wdrożenie nowej wersji planujemy na porę najmniejszego ruchu i przygotowujemy możliwość szybkiego powrotu.
Co z pakietami, które nie mają nowej wersji?
Wymieniamy je na utrzymywane odpowiedniki albo zastępujemy własnym kodem, jeśli pakiet robił niewiele. Tę listę przygotowujemy na etapie inwentaryzacji, żeby nie była niespodzianką.
Od czego zależy koszt aktualizacji?
Od liczby wersji do przeskoczenia, liczby pakietów i ich stanu, wielkości aplikacji i tego, czy ma testy. Po inwentaryzacji dostajesz plan i estymację.
Czy przy okazji aktualizacji poprawicie też kod?
Aktualizację celowo oddzielamy od przebudowy, żeby wiedzieć, co spowodowało ewentualny problem. Miejsca warte poprawy zapisujemy w trakcie prac i proponujemy jako osobny etap, gdy nowa wersja działa już stabilnie.