Proč používat vývojovou verzi e‑shopu?

V minulosti jsme často čelili situacím, kdy jsme implementovali novou funkci, která však chtěla otestovat, než se na e-shopu zobrazí všem návštěvníkům. Proto jsme postupně, jak rostla složitost našich e-shopů, začali budovat proces, který do vývoje zařazuje novou fázi mezi zpracováním a nahráním úpravy na ostrou verzi. 

Čím větší je komplexnost vyvíjeného systému, tím dříve se projeví potřeba uživatelsky testovat nová rozšíření a úpravy mimo produkční e-shop. Tato situace se samozřejmě týkala i našich projektů. Proto jsme vybudovali proces, který reflektuje tyto potřeby a pracuje s vývojovou a produkční verzí e-shopu.

První fáze je klasická, vývojář na svém počítači programuje určitou funkci na tzv. Localhostu. V druhé fázi, kdy má funkci hotovou, ji nahraje na vývojovou verzi, tzv. DEV verzi e-shopu (ve světě známá jako staging environment). Zde ji může testovat tester, projektový manažer, klient či jeho stakeholdeři. Až poté se nahraje na ostrou, produkční verzi e-shopu tzv. Live.

Vývojová verze je prakticky kopií celého Live projektu. Běží na stejné konfiguraci serveru jako produkční e-shop, ale má vlastní databáze, vlastní oddělené zdrojové soubory, je zaheslovaná a není dohledatelná žádným vyhledávačem. Pro roboty i zákazníky je jednoduše neviditelná. 

Vytvoření DEV verze trvá pár hodin a poté je de facto bezúdržbová. Pouze se na ni nahrávají nové úpravy k otestování. 

Díky DEV verzi se obecně snižuje případná chybovost u nově aplikovaných změn a rozšíření. Novinky publikované na DEVu, můžeme rychle a efektivně odladit. DEV totiž pracuje s aktuální databází, s živými daty, které se aktualizují jednou denně přímo z ostré verze (vše v souladu s GDPR, data jsou očištěna a hashována). Díky tomu snadno odhalíme, zda se např. něco načítá pomalu a rovnou vše optimalizovat. 

Při jakých úpravách je DEV verze užitečná? Například, když se upravuje nákupní proces, dochází k velkým úpravám v jednotlivých fázích nákupního košíku. Nebo když vylepšujeme responzivitu e-shopu. Jako třetí příklad uvedeme implementaci vylepšené filtrace a vyhledávání za pomocí technologie Elastic search. Při této úpravě se nahrazuje původní algoritmus vyhledávání za jiný a to si žádá množství strukturálních úprav. Elastic nezatěžuje servery, může obsahovat agendu synonym, počítá s překlepy atd. To vše v sobě zahrnuje mnoho proměnných, které si můžeme v klidu, bez stresu, že ohrozíme produkční e-shop, otestovat právě na DEV verzi. 

Zakomponování práce s DEV a vývojovým serverem si žádá změnu procesu v rámci auto-deploy. Auto-deploy je zautomatizovaný proces přenosu úprav na server. Tuto záležitost máme nastavenou pro DEV i pro Live verzi, přenáší se nám automaticky po změnách v GITu. Do automatizace je třeba zapojit composer, pomáhající automatickému stahování a verzování knihoven. Další otázkou při zavedení Dev verze, kterou je třeba řešit je konfigurace celého e-shopu a jeho modulů. Jde např. o API klíče, které nemohou být shodné na DEVu, jako na ostré verzi (např. platební brány nebo třeba Balíkobot). 

U DEV verze je třeba myslet na to, aby se např. nezaslal reálný štítek na Balíkobot či nepropsal konverzní kód do Google Analytics, Heureky a jiných externích systémů z DEV verze e-shopu. 

Obecné rozdělení DEVu a produkčních verzí je u e-shopů na míru dlouhá léta běžnou a doporučovanou praxí. Napomáhá k bezpečnějšímu testování větších úprav, pomáhá jak klientovi, tak vývojářům k eliminaci případných chyb na produkčním serveru.