Miért választjuk szét következetesen a kód- és adatbázis-migrációt a TYPO3-frissítéseknél

Elsőre ez az állítás szinte ellentmondásosnak hangzik.

Természetesen minden TYPO3-telepítésnek végig kell haladnia a hivatalos frissítési útvonalon. Az adatbázis-migrációk, az upgrade wizardök és a breaking change-ek jó okkal léteznek. Senkinek sem szabad megkerülnie vagy lerövidítenie ezeket a mechanizmusokat.

Ez azonban nem feltétlenül jelenti azt, hogy a teljes fejlesztési folyamatnak is pontosan ugyanazt a sorrendet kell követnie.

Pontosan ez a megkülönböztetés változtatta meg alapjaiban a nagyobb TYPO3-frissítésekhez való hozzáállásunkat.

A klasszikus út technikailag teljesen helyes

Aki már több TYPO3-frissítést végzett, ismeri a szokásos menetet.

A projektet először a következő támogatott fő verzióra emelik. A kódot épp annyira igazítják ki, hogy a rendszer újra működőképes legyen, majd lefuttatják az upgrade wizardöket, eltávolítják a deprecationöket és stabilizálják az alkalmazást. Csak ezután kezdődik ugyanez a folyamat a következő TYPO3-verzióra.

Ez a menet működik.

Következetesen a TYPO3 mag fejlődését követi, és biztosítja, hogy minden adatbázis-változás és minden technikai módosítás az előírt sorrendben történjen.

Sokáig pontosan így dolgoztunk.

Minden nagyobb projektnél azonban egyre inkább az volt az érzésünk, hogy fejlesztési időnk jelentős részét olyan munkába fektetjük, amely a tényleges célrendszer számára alig teremt maradandó értéket.

Ugyanazt a problémát többször megoldani

Egyszerű példa erre az API-változások esete.

Egy klasszikus frissítés során egy metódust gyakran először csak annyira modernizálnak, hogy TYPO3 9 alatt működjön. Néhány nappal később ugyanazt a részt újra módosítani kell, mert a TYPO3 10 más követelményeket támaszt. Ezt követik a további változtatások a TYPO3 11-re, a TYPO3 12-re és végül a TYPO3 14-re.

Technikailag ezzel semmi gond nincs.

Mérnöki szempontból azonban kellemetlen mellékhatás keletkezik.

A fejlesztő többször is foglalkozik ugyanazzal a kódrészlettel, holott a tényleges cél már régóta adott.

Az eredmény gyakran köztes megoldások sora, amelyek kizárólag azért jönnek létre, mert a fejlesztési folyamat az egyes verziólépéseket követi.

A későbbi rendszer számára ezeknek a köztes megoldásoknak nincs maradandó értékük.

Csupán arra voltak szükségesek, hogy elérjük a következő köztes verziót.

Egy idő után elkezdtük megkérdőjelezni pontosan ezt a fajta munkát.

Két teljesen különböző feladat

A tényleges fordulópont akkor jött el, amikor a frissítést már nem egyetlen folyamatként, hanem két különböző, teljesen eltérő célú feladatként kezdtük szemlélni.

Az első feladat az adatbázist érinti.

Itt alig van mozgástér. A TYPO3 mag hivatalos upgrade wizardjeit le kell futtatni. A táblák megváltoznak, a mezők migrálódnak, az adatstruktúrák módosulnak, a meglévő tartalmak pedig új sémába kerülnek át. Ez a menet a TYPO3 magot követi, és a lehető legpontosabban be kell tartani.

A második feladat az alkalmazáskódot érinti.

Itt egészen más kérdés merül fel.

Nem ez:

„Hogyan vigyük át ezt a kódot a lehető leggyorsabban a TYPO3 9-re?"

Hanem ez:

„Hogyan nézzen ki ez a kód, amikor a projekt végül a TYPO3 14.3-on fut?"

Ennek a két kérdésnek meglepően kevés köze van egymáshoz.

Az adatbázist az út érdekli.

Az alkalmazáskódot kizárólag a cél érdekli.

A célunk a célarchitektúra

Ez a felismerés jelentősen megváltoztatta a projektjeinket.

Ma egy nagyobb frissítés elején először a célarchitektúrát határozzuk meg.

• Melyik TYPO3-verziót szeretnénk hosszú távon üzemeltetni?
• Melyik PHP-verziót használjuk?
• Mely API-kat szeretnénk alkalmazni?
• Mely harmadik féltől származó kiterjesztések maradnak meg?
• Mely komponenseket cseréljük le?

Csak miután ezekre a kérdésekre választ kaptunk, kezdjük el a tényleges modernizációt.

Így sok olyan köztes megoldást kerülünk el, amelyeket később úgyis el kellene távolítani.

A kód a kezdetektől a későbbi architektúra irányába fejlődik, és nem egy olyan köztes verzió felé, amelyet néhány nappal később már el is hagyunk.

Eszközeink szerepe

Ez a munkamódszer azonban automatizálás nélkül aligha lenne kivitelezhető.

Sok éven át ezért olyan eszközöket fejlesztettünk, amelyek pontosan ezt a szétválasztást támogatják.

Fontos összetevő a belső kiterjesztésünk, a Legacy Updater.

Ez összefogja a különböző TYPO3 mag upgrade wizardöket, a projektekben bevált migrációs rutinokat, saját Rector-szabályainkat és számos segédszkriptet, amelyeket sok frissítési projektben újrahasznosítunk.

A kiterjesztés neve közben szinte mellékes.

A lényeg a mögötte álló gondolat.

Ha egy adott migrációs lépés már több projektben szükséges volt, akkor nem kellene minden alkalommal újra kifejleszteni.

Ugyanez vonatkozik a tudásbázisunkra is.

Minden projekt után dokumentáljuk a problémákat, a megoldásokat és a tipikus buktatókat. Egyes felismerésekből később how-to-k lesznek, másokból Rector-szabályok vagy új funkciók a Legacy Updateren belül.

Minden frissítéssel így nem csupán a tapasztalatunk gyarapszik.

Maga a folyamat is jobbá válik.

Az automatizálás nem helyettesíti az architektúrát

Ezen a ponton gyakran félreértés keletkezik.

Aki automatizálásról beszél, könnyen azt a benyomást kelti, hogy egy frissítés jórészt gombnyomásra elvégezhető.

Tapasztalatunk az ellenkezőjét mutatja.

Egyik legutóbb lezárt vállalati projektünkben a Rector a tényleges migráció nagyjából negyven százalékát tudta átvenni.

Ez lenyűgöző.

Ugyanakkor azt is jelenti, hogy a hatvan százalékhoz továbbra is tapasztalt fejlesztőkre volt szükség.

Nem azért, mert a Rector elégtelen lenne.

Hanem mert az architekturális döntéseket nem lehet automatizálni.

Egy tizenöt éve éles üzemben futó pi-alapú kiterjesztést nem lehet pusztán egyetlen szabállyal Extbase-re migrálni.

Egy egyedileg fejlesztett backend modult nem lehet automatikusan a modern TYPO3-koncepciókhoz igazítani.

Az üzleti logika pedig nem a szintaxisból születik.

Éppen ezért fektetünk olyan sok időt az automatizálásba.

Nem azért, mert fejlesztőket szeretnénk helyettesíteni.

Hanem mert azt szeretnénk, hogy ők pontosan ezekre a feladatokra tudjanak összpontosítani.

Miért éri meg ez a ráfordítás

Kívülről nézve a megközelítésünk elsőre több munkának tűnik.

• Belső eszközök
• Ellenőrzőlisták
• Telepítési szkriptek
• Regressziós tesztek
• Egy tudásbázis
• Saját Rector-szabályok

Ezeket a befektetéseket a végfelhasználó közvetlenül egyiknél sem látja.

Hosszú távon azonban jelentősen megváltoztatják egy projekt gazdaságosságát.

Minél reprodukálhatóbbá válik egy frissítés, annál kevesebb időt töltenek a fejlesztők visszatérő rutinfeladatokkal.

Minél jobban ellenőrizhetők automatikusan a változtatások, annál kisebb lesz a kézi regressziós tesztelés ráfordítása.

És minél strukturáltabban van előkészítve egy go-live, annál kisebb lesz a kockázat közvetlenül az éles átállás előtt.

A mérnöki munka a mi felfogásunkban ezért nem azt jelenti, hogy gyorsabban programozunk.

A mérnöki munka azt jelenti, hogy a felesleges munkát rendszeresen kivesszük a folyamatból.

Egy frissítés nem ér véget a go-live-val

Talán ez a legnagyobb különbség a korábbi munkamódszerünkhöz képest.

Korábban egy projekt egy sikeres migrációval ért véget.

Ma ott gyakran csak elkezdődik a tényleges javítás.

Minden frissítés után megkérdezzük magunktól, mely felismeréseket tudjuk újrahasznosítani a jövőbeli projektekben.

• Mely lépések automatizálhatók?
• Mely problémák merültek fel ismét?
• Melyik dokumentáció takarított volna meg időt?
• Melyik döntést hoznánk meg legközelebb korábban?

Pontosan ezekből a kérdésekből születnek új eszközök, új szabályok és új folyamatok.

Ezért ma már nem egyetlen projektként tekintünk egy frissítésre.

Lehetőségként tekintünk rá, hogy a teljes mérnöki folyamatot továbbfejlesszük.

Mit tanultunk ebből

Amikor ma visszatekintünk az első nagyobb TYPO3-frissítéseinkre, sok mindent másképp szerveznénk meg.

Nem azért, mert az akkori megoldások technikailag hibásak lettek volna.

Hanem mert ma világosabban megkülönböztetjük azt, amire a TYPO3-nak egy sikeres migrációhoz szüksége van, attól, amire egy mérnöki csapatnak egy gazdaságos és reprodukálható projektmenethez szüksége van.

Az adatbázis a hivatalos frissítési útvonalat követi.

Az alkalmazáskód a célarchitektúrát követi.

Ez a szétválasztás elsőre technikai részletnek tűnhet.

Számunkra azonban az egyik legfontosabb lépés volt ahhoz, hogy a nagy TYPO3-frissítéseket tervezhetőbben, hatékonyabban és magasabb minőségben valósítsuk meg.

És pontosan ezért beszélünk ma a frissítési projekteknél jóval gyakrabban folyamatokról, mint verziószámokról.