Jeden z největších klientů SiteOne cestovní kancelář Blue Style přešel na novější verzi PHP. Vývojáři se při tom nevyhnuli nepříjemným překvapením, avšak nechyběla ani ta příjemná.

• Co by poradili kolegům, kteří se připravují na podobně rozsáhlý úkol?

• Co je překvapilo?

• A proč byla aktualizace potřeba?

Skriptovací programovací jazyk PHP používá 77 % všech webových stránek, u kterých víme, jaký programovací jazyk na serveru upřednostňují. Ze všech těchto stránek podle nejaktuálnějších statistik na W3Techs běží 72 % na zastaralejší verzi PHP 7, zatímco na novou PHP 8, jako je tomu v případě Blue Style, přešla pouze 3 %. Ve spoustě ohledů je přitom aktualizace naprosto klíčová.

“Přechod z PHP 7 na PHP 8 může vypadat jako skok z jedné verze na druhou, ale je to složitější. Do té doby běžel web na verzi 7.1, následovala 7.2, 7.3 a 7.4, takže to není skok o jednu verzi, ale o 4 velké verze. Tím pádem došlo k plno změnám. Původní verze byla 4 roky stará, takže byl problém aktualizovat používané balíčky,” hodnotí Filip Mikovčák, hlavní backendový vývojář Blue Stylu.

Nové verze PHP s sebou přinášejí nepopiratelné výhody. V první řadě poskytuje webu kvalitnější zabezpečení, příjemnou změnou jsou i nižší nároky na paměť a procesor a s tím spojená vyšší rychlost. V neposlední řadě se pak v takové verzi programátorům lépe pracuje. U PHP 8 je možné zpozorovat i záměr o eliminaci zmatků a transparentnější postupy.

 “U nové verze PHP je to většinou tak, že ji vývojáři zhruba rok aktivně vyvíjejí a přidávají nové funkce. Pak může do světa, přitom vývojáři stále aktualizují předchozí verzi, ale už jenom opravují chyby. Starší verze vydrží živá zhruba ještě rok až dva, ale po této době je označena za starou a další chyby nikdo neopravuje. Zranitelnosti, které z toho plynou, je možné vyhledat Googlem, tím pádem například 5 let staré verze může někdo zneužít ve svůj prospěch,” vysvětluje Filip.

Zelená = aktivní podpora: Vývojáři opravují nahlášené chyby a bezpečnostní problémy.

Žlutá = pouze opravy: Vývojáři opravují jen kritické bezpečnostní problémy, nové verze vznikají jen podle potřeby.

Červená = “end of life”: Verze PHP už není podporovaná. Uživatelé by měli co nejdříve provést upgrade, protože jsou vystavení velkému nebezpečí.

Mezi další důležité změny, které nastaly s PHP 8, patří vrácení výjimek TypeError a ValueError pro interní funkce. Aktualizace vylepšila mechanismy používané k porovnání různých druhů proměnných, pořadí zřetězení nebo ověřování typů pro aritmetické a bitové operace. Taky odstranila schopnost staticky volat metody, které nejsou statické.

Aby vývojáři konkrétních projektů ušetřili při modernizaci kódu co nejvíce času, stahují si tzv. balíčky, které umí například propojit dvě knihovny nebo slouží pro práci s databází, aby s ní nemuseli komunikovat napřímo. “Balíčky usnadňují programátorům práci a umožňují jim ovládat jednoduché funkce. Vyvíjet taková řešení by dalo interně dost práce. Pokud neaktualizujeme na novější verze PHP, nemůžeme aktualizovat ani balíčky a některé funkce bychom museli dopisovat ručně. A když jsme používali 4 roky staré PHP, byly mezi balíčky už velké rozdíly,” popisuje Filip další důvod pro neprodlenou aktualizaci.

Taky prozradil, že zjednodušování kódu, a tím pádem usnadňování zápisu, se říká syntaktický cukr. Můžeme to chápat tak, že nová verze je v podstatě stejná, ale její zápis je zjednodušený. V programovacím jazyce se optimalizují funkce a přidává pár novinek. Běžný uživatel si může všimnout maximálně o něco rychlejšího načtení stránek, avšak v metrikách zpozorujete změnu okamžitě. Stačí si porovnat poslední den starého nastavení a den aktualizace.

Zatímco práci designového oddělení a částečně frontendu uvidíte okamžitě, práce backendu se promítá do základů fungování webu, které běžný uživatel webu nemůže ocenit. O to těžší bývá klientovi vysvětlit, že je zásah backendu skutečně potřeba. Navíc nejde o záležitost pár hodin, čas strávený na projektu se může vyhoupnout i do řádu stovek hodin.

“Původní odhad práce na projektu jsme podcenili, počítali jsme s přibližně 100 hodinami. Nakonec jsme na tom strávili něco kolem 250 hodin. U aktualizací se čas velmi špatně odhaduje, navíc jde i o to přesvědčit klienta, aby zaplatil nemalý objem hodin za něco, co vlastně není vůbec vidět,” přiznává Filip. Zároveň ale jedním dechem dodává, že už byla změna opravdu potřeba.

A pokračuje: “Upgrade děláme tak, že zkusíme aktualizovat balíčky a pustíme je na novém PHP. Jakmile pak otevřeme nějakou stránku, začne nám vyhazovat chyby. My je opravíme, refreshneme, vyskočí další chyba a tu znovu opravíme. Nedá se odhadnout, jestli nás čekají 3 chyby nebo jich budou 3 tisíce, obzvláště u tak velkého klienta, jakým je Blue Style."

I ti nejzkušenější programátoři se mohou zaseknout na záludnosti. Filip popisuje jako příklad případ, kdy se na stránce v CMS zobrazovala stránka, na které měl být výpis tabulky hotelů s hvězdičkami, ale místo toho se tu ukazovala chyba na základě nedostatku paměti.

“Přišli jsme na to, že problém je v tom, že se ve starší verzi porovnával text a číslo, písmeno n se ukázalo menší než jedna a to bylo vyhodnocené jako true, zatímco v novější verzi jako false,” vysvětluje Filip. “A tento malinkatý, ale zásadní rozdíl způsobil, že místo žádaného počtu hvězdiček se ukazovala podmínka, kolik jich tam má být, jako nesplněná, takže vzorec jel donekonečna a vypisoval miliardu hvězdiček, tím pádem se vyčerpala paměť."

Mezi další “nenápadné” problémy Filip zařadil komplikace s funkčností balíčků pro fulltextové vyhledávání, kdy každý balíček požadoval jinou verzi systému. Programátoři zkusili nejnovější, pak nižší, ale balíčky pak nebyli kompatibilní jeden s druhým. U rozklíčování se zasekli celý jeden den.

Nejpodstatnější částí aktualizace je důkladný testing, který vývojářům zabral dvě třetiny z celkového součtu hodin. Část kódu je pokrytá různými formami automatizovaných testů, ale ty nejsou 100% zárukou, že projekt i jako celek funguje správně, proto je vždy nutné testovat i ručně.

“Proklikali jsme úplně každou stránku na webu i v CMS, zkoušeli jsme různé procesy na pozadí, stránky, na kterých se něco generuje, zkoušeli jsme to v průběhu vývoje, pak jsme to samé testovali s testery znovu a znovu dokola na preview, dokud už jsme nenacházeli žádné chyby. Při pravidelném release se takto důkladně netestuje,” popisuje Filip.

Finální stav pak backend developeři připravili na stagingu a tam se testovalo znovu. Kromě testerů tam testoval už i klient. To trvalo delší dobu, mezitím vývojáři dělali pravidelné releasy a na stagingu museli přepínat verze PHP. Díky opakovanému testování a přípravám na release měli všechno tak důkladně připravené, že během nasazení dokonce nedošlo k žádnému výpadku.

DevOps, složenina slov Developers a Operations, označuje ty, kteří pečují o komunikaci mezi vývojáři, servery a sítěmi. V SiteOne mezi ně patří kolega Petr Kubečka, který připravil nové PHP na vývojové i testovací prostředí, aby až do nasazení nebylo nic potřeba. Po nasazení trvale promítl novou verzi PHP i do produkce a na všechna náhledová prostředí.

“Po přepnutí jsme museli důkladněji sledovat grafy a metriky, jestli se něco nezhoršilo a do monitoringu nepadají chyby. Jinak nám vyhodnocení metrik chodí každý den v reportu z monitoringu. Jsou tam různé oblasti jako frontend, backend nebo třeba stav serveru. Úspěch aktualizace jsme pak pozorovali z výsledků pár minut starých a sledovali, jestli na grafech nedošlo k nějakým pohybům,” říká Filip. “Byli jsme připravení nasadit pro případ výpadku po dobu releasu údržbovou stránku, než se web zase spustí. Nasazení bylo připravené a proběhlo bez jakéhokoliv výpadu, takže jsme ji nakonec ani nepotřebovali."

Aktualizace byla napínavá do posledních okamžiků. Po nasazení sice web Blue Style nespadl, ale výkon se namísto zlepšení zhoršil. Zjistili, že je problém v “opcache”, protože je v nové verzi PHP špatně nastavená, respektive vypnutá. “Konfigurace byla sice v obou verzích stejná, ale v PHP 8 to nefungovalo. Petr vyzkoumal, jak to správně nastavit, přepnul konfiguraci, grafy zase klesly a všechno běželo, jak mělo,” popisuje Filip.

Jak už jsme naťukli o pár řádků výše, bez aktualizace na novější PHP je web víc a víc ohrožený útočníky. I před velkou aktualizací museli vývojáři jednotlivé balíčky průběžně záplatovat, protože kdyby nedělali ani to, web by obsahoval zneužitelné zranitelnosti. Stačí k tomu jen vyhledat třeba přes Google známé zranitelnosti, zkopírovat si skript a prostřednictvím napadených stránek “nakazit” další weby.

Aktualizace má i další podstatný důvod. Náš obor je dynamický, stejně tak i celá firma, proto je nasnadě, že neustále rosteme. A nalákat vývojáře na “prehistorické” projekty (například 10 let staré), by bylo velmi obtížné. Pokud se nám ale daří přejít na PHP 8, uslyší na to mnohem lépe. Web Blue Style zároveň patří k našim největším projektům, takže máme z úspěšné aktualizace o to větší radost.

“Plno menších projektů se naprogramuje a umře v té verzi, ve které vznikly. Často se děje to, že se po pár letech namísto aktualizace napíše úplně nový web v nejnovější verzi programovacího jazyku, s novým designem, protože je to tak jednodušší. Jde ale o weby, které mají 2 nebo 3 stránky plus třeba vyhledávání nebo formulář, takže vytvoření celého takového webu je otázka pár dnů. Jenomže u Blue Style jsme v reálném čase napojení na systém cestovní kanceláře, který je napojený zas dál, a často trvá dostat odpověď od systému i několik vteřin. Plno dat musíme buď načíst od klienta a nějak zpracovat, nebo synchronizovat na pozadí a uložit v databázi, takže je to o něco složitější. V tomto případě je mnohem výhodnější kód aktualizovat a udržovat jeho kvalitu na dobré úrovni ,” doplňuje Filip.

Ať už se na aktualizaci chystáte v nejbližší době nebo vás čeká v horizontu následujících dvou let, je na místě udělat velmi střízlivý odhad počtu pracovních hodin, které s ní strávíte. “Hodně záleží i na tom, o jak velký a jak dobře udržovaný projekt jde. Někde stačí aktualizovat balíčky, přepnout na nové PHP, doladit pár detailů a je hotovo. Obecně platí, že čím větší projekt, starší projekt,více balíčků, tím více komplikací, práce a testování,” vysvětluje Filip.

 Vývojářům zároveň přeje pevné nervy. “Nedá se předpovídat, jestli se v jedné verzi vyhodnotí výraz takhle a v druhé zase jinak. Chyba taky nemusí na webové stránce vyskočit na první dobrou a může se odhalit až v produkci při nějakém nestandardním scénáři. V některých případech budete zase mile překvapeni, jako třeba já, když se nám povedly téměř všechny balíčky úspěšně aktualizovat jediným příkazem,” uzavírá svou zkušenost Filip.