Modernizacja i przejęcie systemu PHP oraz Laravel bez przestoju
Stary system nie musi znikać, żeby przestał być ryzykiem. Przenoszę żywe projekty na wspierane wersje krok po kroku, z testami tam, gdzie awaria kosztuje najwięcej, i z planem wycofania każdej zmiany.
Objawy, które zwykle nas do siebie prowadzą
- Hosting przysyła informację, że wersja PHP przestaje być wspierana, a system nie chce się uruchomić na nowszej.
- Ostatnia zmiana w kodzie była dawno, a nikt w firmie nie wie, co się stanie po kolejnej.
- Autor systemu przestał odpowiadać albo zmienił branżę.
- Biblioteki nie dostają już poprawek bezpieczeństwa, a audyt albo ubezpieczyciel pyta o to wprost.
- Każda nowa funkcja wyceniana jest wysoko, bo „trzeba przy okazji ruszyć pół systemu”.
Żaden z tych objawów nie oznacza, że system trzeba wyrzucić. Zwykle oznacza, że przez kilka lat nikt nie robił małych kroków i teraz trzeba je zrobić naraz.
Przegląd na start
Zaczynam od przeglądu kodu i infrastruktury. Sprawdzam, na czym to stoi, jakie biblioteki są przeterminowane, gdzie są integracje, co jest testowane i czy da się postawić środowisko od zera na czystej maszynie. Ten ostatni punkt bywa najbardziej bolesny, bo pokazuje, ile wiedzy istnieje tylko w głowie poprzedniego wykonawcy.
Wynikiem jest lista: co grozi naprawdę, co jest kosmetyką i w jakiej kolejności to robić. Dopiero z niej powstaje zakres i wycena.
Jak wygląda aktualizacja bez przestoju
- Kopia produkcji. Pracuję na środowisku odtworzonym z produkcji, z danymi pozbawionymi wrażliwych informacji.
- Siatka testów w newralgicznych miejscach. Najpierw testy tam, gdzie awaria kosztuje najwięcej: logowanie, płatności, dokumenty, integracje.
- Wersja po wersji. Przechodzimy kolejne wersje PHP i Laravela po kolei, zamiast skakać przez pięć naraz. Po każdym kroku system musi działać.
- Zmiany w bazie osobno. Struktura bazy zmienia się mniejszymi krokami, żeby dało się wycofać pojedynczą zmianę bez cofania całości.
- Wdrożenie poza godzinami pracy. Z planem wycofania i kopią zapasową sprzed zmiany.
- Obserwacja po starcie. Monitoring błędów przez pierwsze dni, bo część problemów widać dopiero pod prawdziwym ruchem.
Przejęcie systemu po innym wykonawcy
Przy przejęciu pierwsze tygodnie są najważniejsze, bo wtedy ustala się, czy w ogóle masz kontrolę nad własnym systemem. Zbieramy dostępy do repozytorium, serwera, domeny, bazy i usług zewnętrznych, ustawiamy kopie zapasowe i sprawdzamy, czy da się odtworzyć system z tego, co jest.
Dopiero potem ma sens rozmowa o nowych funkcjach. Szczegółową listę rzeczy do sprawdzenia opisałem w tekście przejęcie strony po innym wykonawcy.
Co dostajesz
System na wspieranych wersjach, z kopiami zapasowymi i monitoringiem, z testami w miejscach, które najbardziej bolą, i z dokumentacją, która pozwala uruchomić projekt bez rozmowy ze mną. Do tego lista rzeczy odłożonych świadomie, z powodem, żeby następna osoba nie musiała ich odkrywać od zera.
- Wersja PHP i Laravela
- wspierana, z poprawkami bezpieczeństwa
- Wdrożenie
- jednym poleceniem, z cofnięciem
- Testy
- uruchamiane przed każdym wdrożeniem
- Kopie zapasowe
- automatyczne, odtworzenie sprawdzone
- Monitoring
- powiadomienie, zanim zauważy klient
- Wersja PHP i Laravela
- bez wsparcia, luki bez poprawek
- Wdrożenie
- ręczne, bez drogi powrotnej
- Testy
- brak, każda zmiana to zakład
- Kopie zapasowe
- nieregularne, nigdy nieodtwarzane
- Monitoring
- brak, awarię zgłasza klient
Utrzymanie po modernizacji możesz zostawić mnie albo prowadzić samodzielnie. Jeśli chcesz rozumieć, co realnie grozi przy starym PHP, zacznij od tekstu stary PHP i Laravel: co realnie grozi.
Pytania, które padają najczęściej.
-
Da się zrobić aktualizację bez wyłączania systemu?
W większości przypadków tak. Pracuję na kopii środowiska produkcyjnego, przenoszę system wersja po wersji, a zmiany wdrażam wtedy, gdy ruch jest najmniejszy. Użytkownik widzi co najwyżej krótkie odświeżenie, a nie komunikat o przerwie technicznej.
Wyjątkiem są zmiany w strukturze bazy przy dużych tabelach: wtedy planujemy okno serwisowe z góry i mówimy o nim z wyprzedzeniem, zamiast ryzykować w biegu.
-
Nie mamy testów. To przekreśla projekt?
Nie, to typowa sytuacja. Zaczynam wtedy od testów na tych fragmentach, które najbardziej bolą, gdy przestaną działać: logowanie, płatności, wystawianie dokumentów, integracje.
To wystarczy, żeby aktualizacja przestała być skokiem na główkę. Reszta testów dokłada się przy okazji zmian, a nie jako osobny, wielomiesięczny projekt.
-
Przepisać od zera czy modernizować?
Przepisanie od zera brzmi czysto, ale zwykle oznacza, że przez rok firma płaci za dwa systemy i nie dostaje nic nowego, a wiedza zaszyta w starym kodzie znika po drodze.
Zaczynam od przeglądu i mówię wprost, co da się uratować, a co trzeba napisać na nowo. Czasem odpowiedź brzmi: przepisujemy jeden moduł, a resztę aktualizujemy.
-
Przejmiesz system, którego autor nie chce już wspierać?
Tak, to częsty scenariusz. Pierwszy krok to zebranie dostępów i kodu oraz sprawdzenie, czy da się postawić środowisko od zera. Dopiero potem rozmawiamy o zmianach.
Jeśli dostępy są niepełne, mówię o tym od razu, bo to zwykle największe ryzyko w takich projektach. Co sprawdzić po swojej stronie, opisałem w tekście o przejęciu strony po innym wykonawcy.
Napisz kilka zdań o swoim przypadku.
Napisz, na czym system stoi dzisiaj, kto go pisał i co przestało działać albo czego boisz się dotknąć. Zwykle wystarczy to, żeby powiedzieć, czy zaczynamy od przeglądu, czy od gaszenia pożaru. Pracuję z Gdyni: spotkania na miejscu w Gdyni, Gdańsku i Sopocie, zdalnie w całej Polsce.
Wolisz rozmowę od pisania? +48 511 599 056, w dni robocze.