V minulosti bol Psono.com poháňaný Odoo v11. Odoo je skvelý CMS, no ako sme museli zistiť, aktualizácie sú náročné. Najmä ich modul pre webové stránky nám počas testovania spôsobil mnoho problémov. Odoo v11 dosiahne koniec svojej životnosti na konci roka 2020, takže sme boli nútení nájsť riešenie.
Uvažovali sme o rôznych možnostiach – buď aktualizovať na Odoo v13 a manuálne migrovať všetok obsah a úpravy sami, alebo si na migráciu niekoho najať, prípadne úplne prejsť na nový CMS. Rozhodli sme sa pre kompletnú migráciu Psono.com preč od Odoo. Verziu v11 budeme používať naďalej za firewallom a premigrujeme ju neskôr (zatiaľ sme sa nerozhodli ako).
Dôvody tohto rozhodnutia boli:
- Pre Psono.com máme veľmi malý objem obsahu, ktorý by sme museli migrovať. Hlavne pár blogových príspevkov.
- Migrácia na Odoo v13 by znamenala o 2 roky ten istý problém, keďže aj v13 dosiahne EOL a potencálna migrácia by bola s oveľa väčším množstvom dát.
- Neboli sme veľmi spokojní s možnosťami prispôsobenia webov v Odoo v11. Všetko je extrémne komplexné, keďže ich šablóny sú uložené v databáze.
- Náklady. Najatie niekoho na migráciu by nás stálo aspoň 5000 USD, skôr viac.
- Komunita Odoo bola veľmi aktívna, no vďaka zmenám licencií v posledných rokoch a migrácii funkcií a pluginov za platbu je všetko za paywallom a komunita je mŕtva.
- Psono.com je hlavne statická stránka so statickým obsahom. Ak by sme potrebovali dynamický obsah, môžeme si ho stiahnuť cez API.
Priebeh migrácie
Po rozhodnutí o migrácii sme si museli zvoliť framework. Existujú klasické frameworky ako napr. Hugo, ktorý sme už využívali, no jeho funkcionalita je obmedzená. Počas hľadania alternatív sme objavili niekoľko riešení vo svete Node / React.
Chcel som sem napísať "skvelé riešenia", no myslím si, že v aktuálnom rozbitom stave frontendového vývoja si to žiadne nezaslúži. Rozbité? Spýtate sa prečo? Pamätáte si časy, keď vývojári vedeli vytvoriť stránku s index.html a načítať jquery cez script tag a mohli začať tvoriť weby? Teraz potrebujete npm alebo yarn, rozumieť package.json, webpack skriptom, moderným frameworkom ako Angular či React, ktoré si všetko nesú so sebou. JSX alebo TypeScript. Funkcie ako hot reloading nepracujú spoľahlivo (súbory nie sú monitorované, niektoré zmeny potrebujú kompletný reštart alebo hot reload sa spustí priskoro, takže aj tak musíte stránku manuálne obnoviť) a tak nakoniec zabíjate vývojárske servery a čakáte minúty, kým nabehnú späť (najmä pri väčších projektoch). (Chýba mi obyčajné stlačenie F5 a všetko hneď fungovalo bez problémov!) Nehovoriac o tom, že každého pol roka máme nový framework alebo nástroj a staré veci sa denne opúšťajú. Mohli by sme na túto tému spísať ešte mnoho strán. No späť k téme.
V neprítomnosti rozumných alternatív boli najlepšími voľbami (v čase písania článku) next.js a gatsby. Aspoň tak to vyzeralo podľa článkov o nich. Obe sú rovnako populárne, ak porovnáte Github hviezdičky alebo commity. Jediný rozdiel, ktorý sme si všimli počas počiatočného hodnotenia je požiadavka serverovej komponenty pri next.js, zatiaľ čo gatsby tvorí statické stránky (Prosím neukameňujte ma, ak medzičasom next.js vie bežať aj bez aktívneho servera! :D)
Tak sme sa pohrali chvíľu s Gatsby a vyzeralo to dobre. Ďalším krokom bolo nájsť tému. Gatsby je "nový" nástroj, takže všetky motívy, ktoré sme našli, boli v dosť základnom stave. Tridsať minút a tridsať dolárov neskôr sme mali aspoň vizuálne príťažlivú tému, ktorá pokrývala niektoré požadované komponenty, a začali sme si ju upravovať.
Čo sa týka hostingu, dnes si môžete vybrať z mnohých poskytovateľov, ako Firebase, Netlify, Cloudflare, Vercel, obyčajné GCP Cloud storage alebo AWS Cloudfront, vlastné servery, docker kontajnery na Kubernetes (musel som to spomenúť!), … (Pamätáte si staré časy, keď ste si za 5 € mesačne prenajali webhosting s PHP a MySQL databázou? :D … ale to je už na iný článok…)
Po porovnaní, prečítaní recenzií a overení možných kombinácií (ako Cloudflare pred Firebase) sme ako prvé skúšali Cloudflare. Ako veľkí fanúšikovia ich služieb to bola prirodzená voľba, no ich nástroj wrangler spôsoboval problémy. Najprv hádzal stále nejakú chybu a potom sme sa nevedeli overiť … Počiatočné chyby zmizli na ďalší deň (možno pomohla nová bash verzia), ale problém s autentifikáciou pretrval. Myslím, že som niekde urobil chybu a po niekoľkých hodinách čítania dokumentácie a skúšania rôznych riešení som to vzdal.
Netlify bola ďalší kandidát, ale musíte ho buď pripojiť k git provideru a nechať Netlify stránku zostaviť (chceli sme použiť GitLab CI), alebo manuálne nahrať build výstup. Možno niekde ponúkajú možnosť uploadu výstupu cez API, ale nenašiel som ju. Alternatívou by bol repozitár, kam by sme pushovali už zostavený výstup, čo mi však prišlo zbytočne komplikované… Ďalším problémom pre mňa je ich cenový model – účtujú za člena (!!!) celkom vysokú sumu. Uvedomte si, že ide o hostovanie statickej stránky. Vyjadrenia typu "4× bandwidth" mi pripomínajú časy "férových webhostingov", kde vás vyhodili, keď ste použili príliš veľa…
Ako štvrtú možnosť sme skúšali Firebase (ktorý je na naše cieľové dáta a požiadavky zadarmo) a všetko fungovalo hneď na prvýkrát. Možnosti presmerovaní sú obyčajné, takže mapovanie starých URL na krajšie bolo trochu únavné, ale pár pravidiel stačilo na to, aby všetko fungovalo. Ich cenník vyzerá rozumne a platíte za serverové zdroje. Doplňkové služby je lepšie obchádzať, aby vás nelockli, ale nám stačilo len hostovanie.
Kratšie sme skúmali aj Vercel, no nutnosť prihlásiť sa cez Github a udeliť povolenie "Act on my behalf" ma odradilo ešte pred samotnou registráciou.
Najťažšie bolo preniesť blog. Nakoniec sme všetok obsah prekopírovali ručne. Nie je to nič pre väčší blog, no náš ich mal len pätnásť. Gatsby podporuje viacero mechanizmov, no chceli sme niečo jednoduché, kde by niekto bez technického zázemia vedel pridať nový článok. Rozhodli sme sa pre markdown, takže sme sa museli naučiť, ako povedať Gatsbymu, aby načítaval stránky z markdownov. Samotné rozchodenie nám trvalo asi pol dňa aj s riešením obrázkov. Pekná blogová téma a obrázky ďalší pol deň.
Po prenesení celého obsahu a ďalšom výraznom úprave témy sme kompletne automatizovali nasadenie cez Gitlab CI, takže jednoduché pushovanie automaticky spúšťa build pipeline a všetko nasadí na Firebase.
Prečo Gitlab a nie Github? Github má navrch z historických dôvodov. Aktuálne tam beží minimálne 80% vývojárov a projektov. Gitlab však prináša funkcie. Preto sme sa pred rokmi rozhodli pre Gitlab, kde sa na rozdiel od Githubu vyvíjali inovácií. To sa po kúpe Githubu Microsoftom dramaticky zmenilo – Github Actions sú prelomové, no stále majú pred sebou dlhú cestu, ak chcú dobehnúť Gitlab. Preto sme pre tento projekt zvolili tiež Gitlab, keďže všetky naše projekty hostujeme tam.
Záver
A tu sme teraz:
- Gatsby ako CMS
- Komerčná téma
- Blog poháňaný markdownom
- Gitlab CI pre automatizované nasadenia
- Hosting na Firebase
S týmto výsledkom sme celkom spokojní a nová stránka vyzerá podstatne lepšie!
