Laraveli pärandsüsteemi uuendamine

Laraveli pärandsüsteemi uuendamine: kus algavad tõelised probleemid

“Uuendame Laraveli” kõlab nagu lihtne ülesanne. Kuni avate composer.json faili. Pärandprojekt võib töötada suurepäraselt Laravel 7 või 8 peal, kuid uuendamine kaasaegsele versioonile võib vallandada terve ahela ühilduvusprobleeme.

Siin on mõned kõige levinumad Laraveli pärandsüsteemi uuendamine seotud probleemid.

1. Vana projekti poolt kasutatav pakett ei ühildu uue Laraveliga

See on ilmselt kõige masendavam stsenaarium. Rakendus kasutab paketti, mis töötas Laravel 8 peal täiesti probleemideta:

Laravel 8
└── package-x 2.4

Uuendate versioonile Laravel 11:

Laravel 11
└── package-x 2.4 ❌

Composer keeldub seda installimast, kuna pakett nõuab illuminate/* vanemat versiooni.

Nüüd peate valima:

  • leida uuem versioon;
  • asendada pakett;
  • teha sellest fork (haru) ja seda ise hooldada;
  • või lükata Laraveli uuendus edasi.

Ja mõnikord on pakett hüljatud, mistõttu puudub otsene uuendamisvõimalus täielikult.

2. Composeri sõltuvuskonfliktid Laraveli pärandsüsteemi uuendamisel

Üks uuendus võib tuua päevavalgele konflikte mitme taseme sügavusel.
Näiteks:

Laravel 11
   ↓
requires Symfony 7
   ↓
Package A requires Symfony 6
   ↓
Package B requires Package A

Composer ei suuda kõiki neid nõudeid täita. Masendav on see, et probleemi tekitav pakett ei pruugi olla midagi, mida te otseselt kasutate. See võib olla mõne teise sõltuvuse sõltuvus. Just siin muutubki lihtne raamistiku uuendamine sõltuvuste arheoloogiaks.

3. composer.lock võib säilitada vana sõltuvuste puu

Te uuendate faili composer.json:

"laravel/framework": "^11.0"

Kuid Composer teatab endiselt konfliktidest, sest composer.lock sisaldab vana rakenduse versioone. Lukustusfail esindab eelnevalt lahendatud sõltuvuste puud.

Seega peate mõnikord uuendama mitte ainult Laraveli, vaid hoolikalt valitud rühma seotud sõltuvusi — ilma pimesi composer.lock faili kustutamata ja parimat lootes.

4. Uus Laraveli versioon nõuab uuemat PHP-d

Näiteks:

Vana rakendus:

Laravel 8
PHP 7.4

muutub järgmiseks:

Laravel 11
PHP >= 8.2

Kuid PHP uuendamine võib paljastada veel ühe kihi probleeme. Mõned vanad paketid ei pruugi enam PHP 8.2 toetada. Seega muutub sõltuvuste ahel selliseks:

Laravel upgrade
      ↓
PHP upgrade
      ↓
old packages become incompatible
      ↓
packages need upgrading/replacing
      ↓
application code needs changes

5. Paketil on uus versioon — kuid selle API on muutunud

Seda on lihtne alahinnata. Leiate ühilduva versiooni ja Composer installib selle edukalt. Suurepärane.

Kuid vana kood:

SomePackage::process($data);

võib nüüd nõuda:

SomePackage::process($data, $options);

või on meetod ümber nimetatud, eemaldatud või selle tagastustüüp on muutunud. Seega: Composeri edu ≠ rakenduse edu.

6. Symfony uuendused võivad mõjutada Laraveli rakendusi

Laravel toetub tugevalt Symfony komponentidele. Kui Laravel viiakse üle uuematele Symfony versioonidele, võivad vanema Symfony käitumise põhjal loodud kohandatud kood või paketid lakata töötamast. See on eriti aktuaalne projektide puhul, kus on kasutusel erilahendustena loodud integratsioonid, HTTP-töötlus, konsoolikäsud, e-posti, sündmuste (events) või failisüsteemi funktsionaalsus.

7. Flysystemi uuendused võivad rikkuda failisüsteemi integratsioone

Hea näide on üleminek Flysystem 3-le. Vanas rakenduses võib olla:

Laravel
└── Flysystem 1/2
    └── custom storage adapter

Pärast uuendamist:

Laravel
└── Flysystem 3
    └── old adapter ❌

Laraveli rakendus ise võib olla küll ühilduv, kuid vana Flysystemi API ümber ehitatud kohandatud adapter või pakett ei pruugi seda olla.

8. Autentimispakettidel on oma uuendamisteekonnad

Laravel Passport, Sanctum, Socialite ja teised ökosüsteemi paketid ei liigu tingimata Laraveliga samas tempos. Tulemuseks võib olla:

Laravel → new version
Passport → old version
      ↓
incompatible dependencies

või võite uuendada Passporti ja siis avastada, et autentimisvood, konfiguratsioon või andmebaasi migratsioonid vajavad muudatusi.

9. Pakettide migratsioonid võivad muutuda

See on veel üks salakaval probleem. Pakett võib olla küll õigesti installitud, kuid selle andmebaasi seadistus võib uuemas versioonis töötada teisiti. Uuendate paketti, juurutate rakenduse ja avastate äkki, et oodatud tabeleid, veergusid või indekseid polegi olemas. Seepärast tulebki pakettide uuendusi käsitleda kui rakenduse muudatusi — mitte lihtsalt kui Composeri muudatusi.

10. PHPUnit ja testide komplekt võivad muutuda omaette migratsiooniks

Toodangu kood võib endiselt tunduda korras. Siis aga käivitate:

php artisan test

ja pool testikomplektist ebaõnnestub. Miks? Sest Laraveli toetatud PHPUnit-i versioonid aja jooksul muutuvad ja PHPUnit ise eemaldab aegunud API-d. Seega võib Laraveli uuendamine tähendada ka järgmiste komponentide uuendamist:

Laravel
+
PHP
+
Composer packages
+
PHPUnit
+
test code

11. Konfiguratsioon ja rakenduse struktuur võivad muutuda

Uuem Laraveli versioon võib tuua kaasa teistsuguse vaikestruktuuri või konfiguratsioonikäsitluse. Tekib kiusatus võtta värske Laraveli installatsioon ja kopeerida kõik vanasse projekti. See on sageli halb mõte. Pärandrakendusel on aastatepikkune kohandatud konfiguratsioon, vahevara (middleware), teenusepakkujad (service providers) ja integratsioonid. Eesmärk ei ole muuta vana rakendust värske Laraveli installatsiooni sarnaseks. Eesmärk on viia olemasolev rakendus turvaliselt üle uuele raamistiku versioonile.

Ja just see teebki Laraveli uuendamise keeruliseks. Probleem on harva küsimuses:

“Kuidas installida Laravel 11?”

Tõeline probleem on hoopis:

“Millised osad sellest 7-aastasest sõltuvuste puust saavad tegelikult Laravel 11-le üle minna, ilma et see rakendust katki teeks?”

Enne uuendamist tahaksin teada:

  • Millised paketid takistavad uuendamist?
  • Millised paketid on hüljatud?
  • Millised paketid vajavad asendamist?
  • Milline PHP versioon on vajalik?
  • Millised Symfony/Flysystemi versioonid muutuvad?
  • Milliseid versioone composer.lock hetkel paigal hoiab (pin)?
  • Millistes API-des on tagasiühilduvust rikkuvaid muudatusi (breaking changes)?
  • Milliseid andmebaasi migratsioone see mõjutab?
  • Kas olemasolev testide komplekt käivitub endiselt?
  • Millised ärikriitilised vood vajavad regressioonitestimist?

Sest Laraveli pärandrakenduses on uuendamise teekond sageli keerulisem kui uuendamine ise.

Mis on olnud suurim Laraveli uuendamise takistus, millega olete kokku puutunud — ühildumatu pakett, Composeri konfliktid, PHP või midagi muud?

Loe edasi:

– Süsteemide moderniseerimine avalikus sektoris: praktiline tee kriitiliste süsteemide uuendamiseni ilma häireteta