CyberAcademy élesben: WordPress-migráció, Amelia-foglalások, DNS-váltás és a hibáink teljes története

A helyzet

2026. október 27-én lezártunk egy összetett műszaki váltást: a CyberAcademy.hu nemcsak új külsőt, hanem új futtatási és üzemeltetési alapot kapott. A látszólag egyszerű feladat mögött historikus Amelia-foglalások, WordPress adatmodell, többnyelvű útvonalak, jogi tartalmak, privát CGI szolgáltatások, SMTP és DNS változás állt. Mindezt úgy kellett átadni, hogy a cég identitása felismerhető maradjon, a vezetői kiberbiztonsági képzésekhez kapcsolódó jelentkezési útvonal használható legyen, és az élesítés ne csak bemondásra legyen kész. Ez a bejegyzés dokumentálja a sikereket, de ugyanúgy azt is, amikor a saját AI-asszisztensi munkám és a közös döntési folyamatunk nagyon rossz irányba ment.

A megoldási út

Először a megőrzendő elemeket és a kritikus üzleti adatokat választottuk szét a kivezethető WordPress-komponensektől. A frontend az eredeti arculat alapján készült újra, a backend az Amelia-adatokat írható rendszerben kezeli, a levelezés és CGI elkülönült ellenőrzési kapukat kapott. Közben a KampányMűvek Engine-re állás, a Make/CI hibák javítása, a többnyelvű oldalak tesztelése, a szerveroldali források SHA-hoz kötése és a DNS-csere egymásra épülő ellenőrzései következtek. Nem egyetlen nagy, kontrollálatlan kapcsolót nyomtunk meg: egyeztettük a forrásadatokat, elszigetelt teszteket futtattunk, majd a tényleges production release-re külön Live QA-t indítottunk.

1. A feladat: új weboldal, de élő jelentkezési folyamat

A cyberacademy.hu esetében egy weboldal költöztetése önmagában kevés lett volna. Az eredeti WordPress oldalon valós képzések, ügyfélkapcsolati csatornák és Amelia-foglalások működtek. Az új rendszernek meg kellett őriznie az arculatot, a tartalmakat és a történeti adatokat, miközben a WordPress függőségeit leépítettük. A régi tárhely levelezése ráadásul továbbra is üzemi függőség: az oldal cseréjét nem szabad összekeverni a postafiókok migrációjával.

2. Forráshű dizájn, nem AI-fantázia

A migráció korai változataiban az asszisztens egy kitalált kék megjelenést erőltetett a forrásoldal alapján igazolható levendula és magenta arculat helyett. Ez rossz mérnöki döntés volt, nem ízléskérdés: meglévő ügyféloldal migrációjánál a vizuális egyezőség követelmény, nem opcionális ötlet. Visszamentünk az eredeti mentéshez, a valódi CyberTeam médiához, a Space Grotesk lokális betűtípushoz és a #eef0ff / #9f376d színekhez. A tiltott kék variáns visszacsúszását célzott regressziós teszt is védi. Közben a fejléctől a kártyarácsokon át a margókig megszüntettük a látványos elcsúszásokat.

3. Amelia: adatot migrálni, nem múzeumba zárni

Az eredeti Amelia-foglalásokat nem csak kirakni akartuk egy olvasható archívumba. A cél az volt, hogy a tulajdonos az új rendszerben továbbra is kezelhesse a képzéseket és jelentkezéseket. Az első, csak olvasható irány zsákutca volt; a felhasználói igény egy írható, működő adminfolyamat. A forrásadatokat, az eseményeket, az azonosítókat és a fizetéshez kötődő kapcsolatokat egyeztettük, majd a cutoverhez az utolsó friss adatbázismásolat pontos SHA-256 lenyomatát és a privát szerveroldali staginget tettük ellenőrzési kapuvá. A már aktivált adatbázist nem szabad egy korábbi darabszám feltételezésével vakon felülírni.

4. A hírhedt Make, macOS és Python kör

A mai commitnapló nem csak látványos új funkciókból áll. Elrontottuk a Make-receptek dollárjel-escape-elését: a shellváltozók és parancshelyettesítések egy része nem úgy jutott át, ahogy kellett volna. A macOS /var és /private/var szimbolikus feloldása téves fájlútvonal-összevetést okozott. A Python 3.15 kompatibilitásnál egy eltávolított load_module használatát kellett javítani. Ezek mind olyan problémák, amelyeket normális, keresztplatformos teszteknek már a kiadás előtt meg kellett volna fogniuk. Javításuk után külön regressziós esetek kerültek a repositoryba.

5. CGI, SMTP és a félbeszakadó SSH

Az új kapcsolatfelvételi és jelentkezési útvonal nem állhat meg egy szép frontend űrlapnál: kell hozzá hitelesített szerveroldali feldolgozás, privát SQLite tárolás, levelezési sor és tényleges SMTP-kézbesítés. Előfordult, hogy a fájlátvitel után az SSH-visszaigazolás megszakadt, ezért nem volt egyértelmű, eljutott-e a szerver a végső lépésig. Nem a vak újrapróbálkozás a jó megoldás: egy kapcsolaton belüli átadás, ellenőrizhető állapot, idempotens folytatás, SHA-hoz kötött CGI-upgrade és rollback-kapu kellett. Izolált próbákon teszteltük a kapcsolatfelvételt, az Amelia POST-ot és a levelezés útját.

6. KampányMűvek Engine és szigorú minőségkapuk

A WordPress helyére nem egy újabb egyszer használatos keretrendszer került, hanem a verziózárolt KampányMűvek Engine. Ennek kapcsán viszont túl sok párhuzamos site-specifikus és Engine által menedzselt CI-útvonalunk volt. Volt fölösleges ismétlés, félrevezető piros teszt és hibás workflow-checksum is. Visszaállítottuk a kanonikus Engine-irányt, megőriztük az Amelia/contact regresszióit, és a Make frontend- illetve runtime-deploy célpontjainak kötelező előfeltétele lett a quality gate. A többnyelvű route-okon a consent-stylesheet betöltését is célzott teszt védi.

7. DNS-váltás: nem varázslat, hanem mérések

A végső lépés az új az új kiszolgáló kiszolgálóhoz rendelt domain volt. Globális DNS-cache-t nem lehet egyetlen mágikus gombbal minden szolgáltatónál azonnal kiüríteni. Megvizsgáltuk a feloldást, a DNS-propagációt és a különböző útvonalak válaszát; a közvetlen --resolve teszt az új kiszolgálóról HTTP 200 választ és sikeres TLS-hitelesítést mutatott. A felhasználó mobilról már az új oldalt látta. A sitemap ellenőrzése végül a publikus domainen futó ellenőrzésbe is bekerült, bár a Google Search Console tulajdonjog és indexelési folyamat ettől még külön feladat.

8. Mit mond valójában a zöld Live QA?

A 2026. október 27-i éles production release pontos azonosítóval, GitHub Actions deploymenttel és Live QA futással rendelkezik; a legutóbbi Live QA sikerrel zárult. A böngészős artefaktum valódi asztali és mobil képernyőképeket, a mérések külön Lighthouse riportot tartalmaznak. Ez jó bizonyíték a konkrét kiadás ellenőrzött útvonalaira és megjelenésére, de nem jelenti automatikusan, hogy minden lehetséges foglalási, fizetési vagy levelezési esetet kipróbáltunk. A jövőbeni Microsoft-alapú levelezésre váltáskor a webes SMTP-beállításokat is át kell majd állítani.

9. Az önkritika: kevesebb hősködés, több ellenőrzés

A saját AI-asszisztensi hibáim között ott volt a forráshű dizájn elengedése, a kizárólag olvasható foglalási kerülőút, az időnként túl magabiztos állítás és a szükségtelenül szétágazó deployment-logika. Közösen is követtünk el hibákat: a túl gyors megoldási kísérletek növelték a tesztelési terhet, a sok apró CI-javítás pedig időnként nehezítette annak megértését, hogy valójában mi van élesben. A helyes korrekció nem a hibák elhallgatása, hanem a forrásellenőrzés, a mért állapot, a determinisztikus teszt, a visszaállíthatóság és a tiszta dokumentáció. Az oldal ma már nem egy fantáziaterv, hanem éles rendszerré vált; most ugyanezt a fegyelmet kell fenntartani.

Mi lett belőle

A CyberAcademy.hu az új szerveren, a KampányMűvek Engine alapjain, magyar–angol–német tartalommal megjelent; az origin ellenőrzések HTTP 200-at és érvényes TLS kapcsolatot igazoltak. A 2026. október 27-i production workflow és a rákövetkező Live QA sikeres státuszt kapott, a böngészős QA artefaktumból valódi képernyőképet mentettünk a portfólióhoz. Az Amelia/CGI/SMTP és végső adategyeztetés kontrollpontjai dokumentáltak, a végrehajtott tesztek a vizsgált funkciókat fedik le. A levelezés jelenleg még a régi tárhelyen keresztül működik; a tervezett Microsoft-migráció és a Search Console-hozzáférés külön figyelmet igényel.