At overtage en Laravel-app, når udvikleren er stoppet

Det er et opkald, jeg ofte får. En virksomhed havde en udvikler, freelance eller ansat, som byggede en Laravel-applikation, forretningen nu er afhængig af. Den person er gået videre. Appen kører stadig, men ingen tør ændre i den, og listen over ting, folk gerne vil have ændret, bliver ved med at vokse.

Sådan ser den første uge ud, når jeg overtager en.

Dag ét: kan vi få den til at køre et sted, der ikke er produktion?#

Før jeg læser en eneste controller, vil jeg have koden i et repository, vi selv styrer, appen kørende på min egen maskine og en kopi af databasen, hvor persondata er fjernet. Overraskende tit mangler en af de tre ting: den eneste kopi af koden ligger på serveren, .env indeholder nøgler, ingen kan forklare, eller der er migrations, der ikke længere kan køre fra bunden.

Intet andet er sikkert, før det virker, for hvert af de næste trin kræver et sted at prøve ting af, som ikke er det levende system.

Adgang og ejerskab#

Hvem ejer domænet, DNS, serveren og hosting-kontoen?
Hvilke tredjepartskonti bruger appen (mail, betaling, SMS, lagring), og hvis kort er de tilknyttet?
Hvor ligger backupperne, og har nogen nogensinde prøvet at gendanne en?

En overraskende stor del af risikoen ligger her og ikke i koden.

Versioner#

Tjek PHP-versionen på serveren og Laravel-versionen i composer.lock. En app, der er to major-versioner bagud, er ikke en nødsituation, men det bestemmer rækkefølgen: sikkerhedsopdateringer til frameworket og PHP stopper på et tidspunkt, og springet bliver sværere, jo længere man venter.

Hvad der faktisk kører#

Laravel-apps laver meget arbejde uden for HTTP-requests, og det er der, overraskelserne gemmer sig:

Planlagte kommandoer i console-kernel eller routes/console.php.
Queued jobs, og om en worker faktisk kører på serveren.
Alt i crontab, der går uden om scheduleren.
Webhooks fra betalings- eller fragtudbydere.

Hvis en queue-worker døde for seks måneder siden, har en funktion stille og roligt ikke virket i seks måneder.

Tests, eller manglen på dem#

De fleste apps, man overtager, har få eller ingen tests. Jeg starter ikke med at skrive en komplet testsuite. Jeg skriver en håndfuld tests omkring de flows, der tjener eller taber penge, som tilmelding, checkout og fakturakørslen, så den næste ændring har noget at fejle imod.

Så, og først så, listen#

Med en kørende kopi, styr på adgangene, kendte versioner og et par tests omkring de vigtige flows bliver listen over ønskede ændringer noget, man kan estimere i stedet for at gætte på. Det er som regel derfra, den faste pris for selve arbejdet kommer.

Mere om Laravel-udvikling og vedligehold.