Amikor a hosting már a release-folyamat ellen dolgozott: PogoZone → DigitalOcean

A helyzet

A régi hostinggal nem az volt a fő probléma, hogy egyik napról a másikra használhatatlanná vált. Sokkal kellemetlenebb volt: az évek alatt felhalmozódott működési állapot egyre kevésbé volt átlátható. A WordPress publikus oldal, a kereskedelmi rendszer, a PHP runtime-ok, cron feladatok, fájlok, TLS, DNS, mentések és a levelezés több ponton a szolgáltató környezetéhez kötődtek. Egy release-nél ezért nem csak azt kellett tudni, hogy jó-e az alkalmazáskód, hanem azt is, hogy az adott szerveren éppen milyen kézi konfiguráció, jogosultság vagy régi beállítás tartja életben. Ez különösen rosszul illett ahhoz az irányhoz, amelyben a Columbia Games fejlesztését már Git, CI/CD, Docker, smoke tesztek és reprodukálható release-ek felé vittük. Egy ponton a kérdés már nem az volt, hogy lehet-e még egy ideig maradni, hanem az, hogy mennyi kockázatot termel az a környezet, amelyet nem tudunk ugyanazzal a pontossággal leírni és ellenőrizni, mint az alkalmazást.

A megoldási út

A költözést ezért nem DNS-átírással kezdtem, hanem függőségi térképpel. Külön vettem, mi tartozik a publikus WordPresshez, mi a commerce/CCM működéséhez, hol vannak tartós adatok és feltöltések, milyen háttérfolyamatok futnak, melyik komponens küld levelet, és mi az, amit a domain vagy a régi szolgáltató implicit módon biztosít. Ezután felépült az új DigitalOcean környezet Ubuntu alapon, kontrollált Nginx és TLS konfigurációval, a szolgáltatásoknál pedig ahol értelme volt, Docker-alapú futtatással. A migráció sorrendje tudatosan réteges volt: először a szerver és a hálózati alapok, utána az alkalmazás-runtime-ok, majd a WordPress és a commerce komponensek, az adat és fájlok, végül a külső integrációk, DNS és levelezés. Minden nagyobb lépés után külön smoke ellenőrzés következett, nem egyetlen nagy 'majd a végén megnézzük' teszt. A publikus váltás előtt az új környezetet közvetlenül is teszteltem, így a DNS még nem volt része a hibakeresésnek. A régi környezetet pedig nem az első sikeres oldalbetöltés után tekintettem kidobhatónak: a rollback lehetőség addig maradt fontos, amíg az új szerveren a kritikus webes és háttérfolyamatok nem bizonyítottak együtt.

Mi lett belőle

A DigitalOceanra költözéssel nem csak másik szervert kaptunk, hanem más működési modellt. A production környezet komponensei explicitebbé váltak: látható lett, melyik szolgáltatás miért fut, hol van a konfigurációja, mit kell ellenőrizni deploy után, és melyik réteghez kell nyúlni hiba esetén. Ez tette igazán értelmessé a későbbi GitHub Actions és Make alapú deploymentet, a Dockeres újraépítést, a PageSpeed és smoke ellenőrzéseket, a security hardeninget és a visszaállítható release-folyamatot. A legfontosabb eredmény nem egy alacsonyabb szerverválaszidő vagy egy új IP-cím volt, hanem az, hogy az infrastruktúra megszűnt külön, részben ismeretlen rendszerként viselkedni. A kód, a runtime és a release-folyamat végre ugyanannak a mérnöki rendszernek a része lett.