Upgrade vagy újraépítés? Miért nincs a valódi döntésnek köze a TYPO3-verziókhoz

Ez a kérdés gyakorlatilag minden nagyobb TYPO3-projektet elér egyszer. Minél régebbi egy telepítés, annál gyakrabban merül fel – jellemzően nem a fejlesztőknél, hanem vezetői szinten. Mert ott nem API-król vagy bővítményekről van szó, hanem költségvetésről, kockázatokról és arról a kérdésről, hogy melyik döntés teszi a platformot a következő évekre fenntarthatóvá.

Érdekes módon újra és újra azt látjuk, hogy ez a vita rossz kritériumokkal indul. Verziószámokról esik szó, elavult PHP-verziókról, már nem támogatott bővítményekről vagy a forráskód állapotáról. Mindez természetesen lényeges. Mégis, a mi szemszögünkből egyik téma sem dönti el, hogy érdemes-e az upgrade.

A valódi kérdés sokkal inkább ez:

Mennyi tudás rejlik ma már ebben a platformban – és mennyibe kerülne ezt a tudást újra felépíteni?

A szoftver másképp öregszik, mint az épületek

Csábító a szoftvert egy épülethez hasonlítani. Egy ház egyszer csak régi lesz, az épületgépészet már nem felel meg a kor színvonalának, és előbb-utóbb felmerül a kérdés, hogy van-e még értelme a felújításnak.

A szoftver azonban másképp működik.

Egy tízéves TYPO3-projekt nem automatikusan rossz műszakilag. Gyakran épp az ellenkezője igaz. Az, hogy egy platformot sok éven át folyamatosan használtak, többnyire azt jelenti, hogy valódi üzleti értéket teremtett. A szerkesztők ehhez igazították a munkafolyamataikat, egyedi folyamatokat integráltak, interfészek jöttek létre, és számtalan apró optimalizálást valósítottak meg, amely a világ egyetlen követelményspecifikációjában sem szerepel.

Pontosan ezek a dolgok teszik értékessé egy enterprise platformot. És pontosan ezek nem tűnnek el egyszerűen attól, hogy valaki úgy dönt: „kezdjünk mindent elölről".

Ritkán a kód a valódi probléma

Egy ideje egy ügynökség bevont minket egy upgrade-projektbe, amelynek műszaki kiindulási helyzete első ránézésre valóban az újraépítés mellett szólt.

A platform még TYPO3 8.7-en futott, sok éven át bővült, és mintegy negyven bővítményből, több egyedileg fejlesztett backend-modulból és egy olyan szakalkalmazásból állt, amely mélyen integrálódott a végfelhasználó üzleti folyamataiba. A használt, harmadik féltől származó bővítmények egy részét már rég nem karbantartották aktívan, sok API elavult volt, a projekt egyes részei pedig még abból az időből származtak, amikor a TYPO3_DB volt a szokásos módja az adatbázis-hozzáférésnek.

Jó érveket lehetett volna találni amellett, hogy mindent újrafejlesszünk. A vita kezdetben valóban pontosan ebbe az irányba haladt.

Minél tovább foglalkoztunk azonban a projekttel, annál világosabbá vált, hogy nem a rendszer műszaki állapota jelentette a valódi kihívást. A nagyobb kihívás annak megértése volt, mennyi üzleti logika gyűlt össze ebben az alkalmazásban az évek során.

Sok funkció első ránézésre kicsinek vagy jelentéktelennek tűnt. Némelyik csak néhány sornyi kód volt. Mégis természetessé váltak a felhasználók számára, és naponta használták őket. Egy újraépítés azt jelentette volna, hogy mindezeket a részleteket előbb újra fel kell fedezni, aztán újratervezni, végül pedig újra letesztelni.

A valódi komplexitás tehát nem a kódban rejlett. Hanem a tudásban.

Miért lesznek az upgrade-ek gyakran feleslegesen drágák

Pontosan ezen a ponton változott meg alapvetően a TYPO3-upgrade-ekről alkotott szemléletünk az elmúlt években.

Amikor az első nagyobb upgrade-projektjeinket végeztük, sok más csapathoz hasonlóan elsősorban technikai feladatokban gondolkodtunk. Mely API-kat kell lecserélni? Mely bővítmények kompatibilisek? Mely upgrade wizardokat kell lefuttatni?

Ma ugyanezeket a projekteket teljesen másképp írnánk le. Az upgrade-eket mára mindenekelőtt engineering-feladatnak tekintjük.

Mert a tényleges költségek meglepően ritkán magából a TYPO3-ból fakadnak. Az ismétlődő munkából fakadnak, a bizonytalanságból, a kézi folyamatokból – olyan dolgokból, amelyeket többször el kell végezni, pedig tulajdonképpen csak egyszer lenne rájuk szükség.

Tipikus példa erre egy kódbázis lépésenkénti modernizálása. Sok upgrade-projekt először annyira igazítja a kódot, hogy a TYPO3 9 működjön. Nem sokkal később ugyanazt a helyet újra módosítják, hogy a TYPO3 10 is fusson. Ezután további igazítások következnek a TYPO3 11-hez és a TYPO3 12-höz.

Műszakilag ez az út teljesen helyes. Engineering-szempontból azonban olyan munkát hoz létre, amely kizárólag azért létezik, mert a fejlesztési folyamat a köztes verziókhoz igazodik. A platform későbbi üzemeltetése szempontjából ez a munka nem hoz többletértéket.

Ugyanezt tapasztaljuk a tesztelésnél. Ha minden nagyobb változtatás után kiterjedt kézi regressziós tesztekre van szükség, a ráfordítás és a projektkockázat folyamatosan nő. A valódi probléma azonban nem magában a tesztelésben rejlik, hanem abban, hogy a fejlesztési folyamat túl kevés lehetőséget kínál a hibák korai, automatikus láthatóvá tételére.

Minél gyakrabban láttunk ilyen mintázatokat, annál világosabbá vált számunkra, hogy egy upgrade minősége nem kizárólag attól függ, milyen jól programoznak a fejlesztők. Legalább annyira függ attól, mennyire jól tervezték meg magát az upgrade-folyamatot.

A jó engineering-folyamatok megváltoztatják egy upgrade gazdaságosságát

Ez volt valószínűleg az elmúlt évek legfontosabb felismerése.

Sok cég az engineeringet többletráfordításként tekinti. Szkripteket kell írni. Az automatizált tesztek időbe kerülnek. Deployment-folyamatok épülnek ki. Belső eszközök jönnek létre, pedig az ügyfél később sosem látja őket.

Rövid távon ez igaz is. Mindezek a dolgok időbe kerülnek. Hosszú távon azonban jelentősen megváltoztatják egy projekt gazdaságosságát.

• Egy reprodukálható migrációs folyamat csökkenti az ismétlődő munkát.
• Az automatizált regressziós tesztek csökkentik a kézi tesztelési ráfordítást.
• Egy közös tudásbázis megakadályozza, hogy ugyanazokat a problémákat minden projektben újra megoldják.
• Egy strukturált ellenőrzőlista csökkenti a go-live kockázatát.

Egyik intézkedés sem hoz létre azonnal új funkciót a végfelhasználó számára. Együttesen azonban azt eredményezik, hogy egy upgrade tervezhetőbbé, jobb minőségűvé és gyakran gazdaságosabbá is válik.

A mi szemszögünkből pontosan ez a különbség a fejlesztés és az engineering között. A fejlesztés megold egy problémát. Az engineering arról gondoskodik, hogy ugyanazt a problémát lehetőleg soha többé ne kelljen ugyanúgy megoldani.

Miért döntöttünk az upgrade mellett

A leírt projektben végül pontosan ez a gondolkodásmód vezetett másféle döntéshez.

A projektet már nem egyes TYPO3-verziók sorozataként tekintettük, hanem olyan platformként, amelyet egy új célarchitektúrára kell átemelni. Ebből született az a megközelítésünk, hogy a kód- és az adatbázis-migrációt következetesen szétválasztjuk. Ezáltal sok köztes lépést el tudtunk kerülni, amely egy klasszikus upgrade-folyamatban elkerülhetetlennek tűnik.

Az olyan eszközök, mint a Rector, a TYPO3 Extension Scanner, a saját Legacy Updater bővítményünk, valamint a BackstopJS-szel végzett vizuális regressziós tesztek, fontos építőelemek voltak. A döntő azonban nem az egyes eszköz volt, hanem az, ahogyan együttműködtek.

Minden eszköznek csak egyetlen feladata volt: az ismétlődő munka egy adott kategóriáját tartósan megszüntetni.

Az eredmény nemcsak egy sikeres migráció volt a TYPO3 14.3-ra. A platform ráadásul profitált egy modernebb architektúrából, érezhetően jobb teljesítményből és egy olyan kódbázisból, amely a jövőben lényegesen egyszerűbben fejleszthető tovább.

Mindenekelőtt azonban egy lehetséges újraépítésről szóló vitából olyan upgrade lett, amely gazdaságilag meggyőzőbb volt, mint egy teljes újraépítés. Nem azért, mert a TYPO3 egyszerűbb lett volna, hanem mert megváltoztattuk az engineering-folyamatot.

Mit tanultunk ebből a projektből

Amikor ma visszatekintünk erre a projektre, már alig gondolunk a TYPO3 8.7-re vagy a TYPO3 14.3-ra. A verziószámok végül csak a keretet adták. A valódi felismerés más volt.

Egy enterprise upgrade költségét sokkal inkább az engineering-folyamat határozza meg, mint a közöttük lévő főverziók száma.

Minél jobban sikerül elkerülni az ismétlődő munkát, korán láthatóvá tenni a bizonytalanságot és módszeresen beépíteni a minőséget a folyamatba, annál gazdaságosabbá válik egy upgrade – és egyúttal annál magasabb az eredmény minősége.

Talán pontosan ez a legfontosabb oka annak, hogy ma sokkal ritkábban beszélünk verziószámokról, mint néhány évvel ezelőtt. Nem azért, mert lényegtelenek lennének, hanem mert ritkán jelentik a valódi kihívást.