MUNKANAPLÓ / WORKLOG
Nem case study. Munkanapló.
A kész rendszer önmagában keveset mond arról, hogyan született. Itt a problémák, rossz irányok, javítások, kompromisszumok és ellenőrzések vannak — azok a részek is, amelyek egy portfólió-kártyáról lemaradnak.
18 bejegyzés ezen az oldalon · 103 összesen
102 bejegyzés után nem fordítási backlogot akartunk, hanem kétnyelvű alapállapotot
A teljes Worklog angolítása megmutatta, hogy az utólagos fordítás önmagában technikai adósság. A 102/102 migráció után úgy alakítottuk át a folyamatot, hogy minden új bejegyzés magyarul és angolul egyszerre szülessen, ugyanabban a QA-láncban.
Naplóbejegyzés megnyitása →
A WebP-optimalizálás site-feladatból Engine build feature lett
A PageSpeedben újra és újra ugyanaz a képprobléma jelent meg. Ahelyett, hogy minden oldalon külön scriptet írnánk, az Engine alpha.10 automatikus responsive WebP pipeline-t kapott.
Naplóbejegyzés megnyitása →Az alpha.10 eltörte a site-upgrade CLI-t — ezért most már teszt védi
Az új image feature után egy lifecycle import regresszió miatt a site-upgrade nem működött. A javítás nem állt meg a kód visszaállításánál: valódi upgrade folyamatot futtató regressziós teszt került mellé.
Naplóbejegyzés megnyitása →A dokumentáció, fleet upgrade és CI supply chain ugyanazon a napon lett szigorúbb
A platform érettségét nem egy új frontend feature adta, hanem három kevésbé látványos réteg: kétnyelvű docs parity, visszagörgethető fleet upgrade és pinelt release-infrastruktúra.
Naplóbejegyzés megnyitása →A portfólió mellé Munkanapló került: a kész rendszer önmagában túl keveset mond
A projektkártyák megmutatják, mit építettem. A Munkanapló azt is, hogyan: hibás irányokkal, regressziókkal, deploydöntésekkel, biztonsági korlátokkal és azokkal a részletekkel, amelyek egy CV-ből kimaradnak.
Naplóbejegyzés megnyitása →
Gödi Sittes: a Dzsoni-design maradt, a régi runtime ment
A migráció célja nem egy újratervezett oldal volt. A karakteres vizuál, a HU/EN/DE tartalom és a működő lead flow maradt, miközben a régi build- és management réteget natív KampányMűvek Engine v4 váltotta.
Naplóbejegyzés megnyitása →
Madmasel: platformot cseréltünk úgy, hogy először az oldalt nem változtattuk meg
A működő autós oldal Engine v4 migrációjánál először byte-megőrző átállási bizonyíték kellett. A fejlesztői rendszer, CI/CD és rollback változott, nem az ügyfél által látott artifact.
Naplóbejegyzés megnyitása →Egy contact form kedvéért nem tartottunk életben teljes mail backendet
A régi Namecheap/PrivateEmail alapú PHP mail flow elvesztette az alapját. A statikus oldalhoz végül egyszerűbb és jobban illeszkedő FormSubmit megoldás került, saját köszönőoldallal és CAPTCHA-val.
Naplóbejegyzés megnyitása →Öt site állapotát egy parancsnak kellett igazat mondania
A fleet-status nem egyszerű verziólista lett. Local source, Engine commit, release, deploy és live-QA állapotot kellett egymás mellé tenni úgy, hogy ne jelezzen hamis sikert.
Naplóbejegyzés megnyitása →Az engine és a site végre külön életciklust kapott
A KampányMűvek akkor vált valódi platformmá, amikor a közös motor, generátorok és QA külön repóba kerültek, az oldalakban pedig csak a saját tartalom, template, kép és egyedi ellenőrzés maradt.
Naplóbejegyzés megnyitása →Consent Mode v2: a cookie banner még nem mérési stratégia
A futó Google Ads kampánynál nem volt elég egy látványos consent UI. A mérési parancsoknak ténylegesen a hozzájárulási állapot szerint kellett viselkedniük, telefonos és oldalmegtekintési konverziókkal együtt.
Naplóbejegyzés megnyitása →
32 ezer termékkép miatt nem akartuk a teljes production médiát minden laptopra lemásolni
A lokális CCM fejlesztéshez live legacy media proxy, cache, patient image mode és háttér warmup készült. A cél valós képek használata volt anélkül, hogy startupkor letöltenénk a teljes médiakészletet.
Naplóbejegyzés megnyitása →A live QA-nak azt a SHA-t kell tesztelnie, ami tényleg kint van
A post-deploy QA-t exact production SHA-hoz kötöttük, és PageSpeed API quota esetére helyi Lighthouse fallbacket adtunk. Így a külső szolgáltatás limitje nem tette vakká a release-t.
Naplóbejegyzés megnyitása →A CCM deploy ne indítson újra mindent csak azért, mert volt egy commit
A production pipeline migration-aware és incremental lett: külön felismeri az adatbázis-, runtime-, web- és SEO változást, és csak azt a részt mozgatja, amelynek tényleg kell.
Naplóbejegyzés megnyitása →A backfill gyors volt. Kár, hogy előbb schema kellett volna alá.
A library history migrációnál a schema és backfill sorrendje explicit dependency lett. Az unordered változatokat eltávolítottuk, majd verziózott, rendezett migration ID-k rögzítették a helyes utat.
Naplóbejegyzés megnyitása →A DB backup időpontja a migration előtt van, nem valamikor aznap
A production migration runner közvetlen migration-time adatbázis-mentést és retentiont kapott, mert az éjszakai backup túl távoli állapot lehet egy adatot módosító release rollbackjéhez.
Naplóbejegyzés megnyitása →Kivettük a deployment logikát a GitHub YAML-ból, hogy végre rendesen tesztelhető legyen
A production workflow túl sok shell logikát hordozott inline YAML-ban. A tényleges deploy döntések verziózott, self-testelt szerver scriptbe kerültek, a workflow pedig vékony SSH launcher lett.
Naplóbejegyzés megnyitása →A legutóbbi deploy nem feltétlenül a legutóbbi jó deploy
A change detection és recovery korábban túl könnyen tekintett egy megpróbált production SHA-t jó alapnak. Ezt a last successful runtime SHA fogalmával kellett helyretenni.
Naplóbejegyzés megnyitása →Nincs találat a teljes munkanaplóban erre a keresésre.