Laravel / utrzymanie
Jak bezpiecznie przejąć istniejący projekt Laravel?
Pierwszym celem przejęcia aplikacji jest możliwość odtworzenia jej działania i bezpiecznego wdrożenia małej zmiany. Aktualizacja frameworka może być kolejnym krokiem, ale nie zastępuje poznania systemu.
1. Ustal, co rzeczywiście działa na produkcji
Zbierz repozytorium, identyfikator wdrożonej wersji i opis środowisk. Sprawdź wersję PHP, wymagane rozszerzenia oraz Laravel zapisany w composer.lock. PHP uruchamiany przez serwer WWW, polecenia konsolowe i procesy kolejek nie musi być tą samą wersją. Różnica potrafi wyjaśnić błąd występujący tylko w jednym miejscu.
Porównaj composer.json z plikiem lock i instrukcją instalacji. Na początku odtwórz zależności przez composer install w odizolowanym środowisku. Composer update zmienia zestaw wersji, więc nie jest neutralną czynnością diagnostyczną. Zapisz również sposób budowania zasobów frontendowych i wymagane wersje narzędzi.
2. Przejmij konfigurację bez kopiowania sekretów do repozytorium
Plik .env.example powinien opisywać potrzebne zmienne, ale nie zawierać prawdziwych haseł. Dostępy do infrastruktury i usług przekaż kontrolowanym kanałem, z kontami przypisanymi do osób i możliwością odebrania uprawnień. Sprawdź, kto ma dostęp do produkcji, domeny, poczty, storage i systemu kopii zapasowych.
Nie generuj automatycznie nowego APP_KEY w działającej aplikacji: może to uniemożliwić odczyt danych zaszyfrowanych starym kluczem. Środowisko testowe powinno używać własnych integracji i danych. Jeżeli potrzebna jest kopia produkcyjna, ogranicz ją i zanonimizuj; nie uruchamiaj na niej wysyłki wiadomości do klientów.
3. Sprawdź bazę danych i historię migracji
Ustal silnik i wersję bazy, rozmiar danych oraz zależności od rozszerzeń, widoków czy procedur. Porównaj historię migracji z rzeczywistym schematem. Nie zakładaj, że repozytorium opisuje wszystkie ręczne zmiany wykonane przez lata.
Przed migracją sprawdź kopię zapasową i procedurę jej odtworzenia. Oceń, czy zmiana blokuje dużą tabelę, wymaga uzupełnienia danych albo usuwa kolumnę używaną przez starszy kod. Powrót do poprzedniego wydania aplikacji nie zawsze cofa zmianę struktury bazy. Plan wycofania musi uwzględniać oba elementy.
4. Zidentyfikuj pracę wykonywaną poza żądaniem HTTP
Rozpisz kolejki, ich sterowniki i procesy workerów. Jeżeli używany jest Redis, ustal osobno jego rolę w cache, sesjach i kolejkach. Wspólne polecenie czyszczenia danych może mieć bardzo różne skutki w zależności od konfiguracji.
Sprawdź zadania cykliczne, scheduler i konfigurację cron, w tym strefę czasową oraz zabezpieczenie przed równoległym uruchomieniem. Dla kolejek obejrzyj timeouty, liczbę prób i nieudane zadania. Ponowienie operacji nie powinno przypadkowo wysłać drugiego zamówienia lub drugi raz obciążyć zewnętrznego systemu.
5. Zmapuj integracje i procedurę wdrożenia
Lista integracji powinna zawierać właściciela konta, środowisko testowe, limity oraz sposób rozpoznawania błędów. Sprawdź webhooki, ich podpisy, powtórzenia i kolejność zdarzeń. Testy uruchamiaj z atrapami albo w sandboxie, nie przez przypadkowe wywołania usług produkcyjnych.
Prześledź cały deployment: budowanie artefaktu, konfigurację, migracje, cache, procesy kolejek i kontrolę działania po wdrożeniu. Procesy długotrwałe wymagają uwzględnienia przy zmianie kodu. Ustal także osobę podejmującą decyzję o wycofaniu wydania i warunki tej decyzji.
6. Obserwuj aplikację przed pierwszą zmianą
Przejrzyj logi i aktualne błędy oraz wykonaj najważniejsze scenariusze użytkownika. Zapisz punkt odniesienia: które problemy już występują, jak długo trwają kluczowe operacje i czy kolejki mają zaległości. Sam zielony ekran główny nie potwierdza działania całego produktu.
Uruchom istniejące testy. Jeśli ich brakuje, zacznij od scenariuszy, które najłatwiej uszkodzić: uprawnień, obliczeń, kontraktów API i integracji. Test opisujący obecne zachowanie pomaga odróżnić regresję od świadomej zmiany wymagania.
7. Zaplanuj aktualizacje w osobnych etapach
Sporządź listę zależności niewspieranych, podatnych lub blokujących rozwój. Dla każdej aktualizacji sprawdź przewodnik migracji odpowiedni dla zainstalowanej wersji, kompatybilność PHP i pakietów oraz zakres testów. Nie łącz dużej aktualizacji frameworka z przebudową funkcji biznesowej, jeśli utrudni to znalezienie przyczyny awarii.
Wynikiem przejęcia powinny być: odtwarzalne środowisko, lista dostępów i integracji, opis wdrożenia i rollbacku, testy krytycznych ścieżek oraz priorytety dalszej pracy. Dopiero wtedy można uczciwie oszacować kolejne etapy rozwoju.
Takie przygotowanie jest punktem wyjścia do rozwoju aplikacji Laravel oraz zmian w backendzie i API.
Dokumentacja do dalszej pracy
Instrukcje wdrożeniowe dobierz do wersji używanej w swoim projekcie. Poniższe źródła rozwijają opisane zagadnienia.