Amikor a third-party extensionök megváltoznak: miért nincs szinte soha tökéletes megoldás a TYPO3-frissítéseknél

Aki valaha is korszerűsített már olyan TYPO3-telepítést, amely sok éven át éles használatban volt, ismeri a helyzetet.

Maga a migráció jól halad. A kódbázis korszerűsödik, a deprecationök fokozatosan eltűnnek, az adatbázis-migrációk elő vannak készítve, és a platform közeledik a célverzióhoz. Egy ponton azonban olyan extensionbe ütközünk, amely technikailag ugyan továbbra is létezik, funkcionálisan viszont jelentősen megváltozott.

Az új verzió gond nélkül támogatja a TYPO3 14-et, aktívan karbantartják, és biztonsági frissítéseket kap. Mégis hirtelen hiányzik egy funkció, amelyet az ügyfél évek óta magától értetődően használ.

Ezen a ponton már nem technikai vita kezdődik. Hanem egy termékdöntés.

A szoftver tovább fejlődik – akkor is, ha a saját projekt megáll

Egy TYPO3-telepítést gyakran sok éven át folyamatosan használnak. Eközben nemcsak maga a TYPO3 fejlődik tovább. A használt extensionök is folyamatosan változnak.

• A maintainerek reagálnak az új igényekre.
• Az architektúrák korszerűsödnek.
• A felhasználói felületeket átdolgozzák.
• Új funkciók születnek.
• A régiek eltűnnek.

Részben azért, mert technikailag már nincs értelmük, részben azért, mert csak kevés projekt használta őket, és olykor egyszerűen azért, mert megváltozott egy extension iránya.

A maintainerek szemszögéből ez teljesen érthető. Egy aktívan karbantartott szoftvernek fejlődnie kell.

Egy frissítési projekt számára azonban ez új problémát teremt. Az ügyfél platformját korszerűsíteni kell. Ugyanakkor az ügyfél érthető módon azt várja, hogy a napi munkafolyamatai a lehető legkevésbé változzanak.

Ez a két cél nem mindig egyeztethető össze maradéktalanul.

Három kézenfekvő megoldás – és miért nem tökéletes egyik sem

Az ügynökségekkel folytatott beszélgetésekben többnyire ugyanaz a három javaslat merül fel.

Az első így hangzik: „Akkor a hiányzó funkciót egyszerűen mi magunk fejlesztjük le.”

Technikailag ez gyakran gond nélkül lehetséges. Hosszú távon azonban ezzel felelősséget vállalunk egy egyedi bővítményért, amelyet a jövőben karbantartani, tesztelni és a későbbi frissítéseknél újra figyelembe kell venni.

Egy hiányzó funkcióból saját termékviselkedés lesz.

A második javaslat így szól: „Akkor az ügyfélnek el kell fogadnia, hogy ez a funkció már nem létezik.”

Ez a nézőpont is technikailag megindokolható. Végső soron a szoftver fejlődik.

A felhasználók szemszögéből azonban ez a válasz ritkán érződik kielégítőnek. A tulajdonképpeni megbízás végeredményben nem az volt, hogy üzleti folyamatokat változtassunk meg, hanem hogy egy meglévő platformot korszerűsítsünk.

A harmadik javaslat az, hogy egyszerűen maradjunk a régi extension-verziónál. Ez azonban csupán a jövőbe tolja a problémát. Egy már nem karbantartott extension a további évekkel ritkán lesz könnyebben migrálható. Épp ellenkezőleg: a technikai adósság tovább nő.

Érdekes módon mindegyik megoldás első pillantásra elfogadhatónak tűnik. Általános szabályként mégsem győz meg minket egyik sem.

Ezért az első kérdésünk nem az, hogy „Hogyan oldjuk meg ezt?” Először egy másik kérdést teszünk fel.

Milyen feladatot tölt be tulajdonképpen ez a funkció?

Ez magától értetődően hangzik. Ám meglepően ritkán az.

Hosszú évek éles használata után szinte minden enterprise platformon léteznek olyan funkciók, amelyek történetileg alakultak ki. Némelyiket naponta használják. Másokhoz évek óta hozzá sem nyúltak.

Ezért az ilyen megbeszéléseket alapvetően sosem a technikával kezdjük, hanem a tényleges felhasználási esettel.

• Valóban szükség van-e még ma erre a funkcióra?
• Megváltozott-e a mögöttes üzleti folyamat?
• Van-e már a jelenlegi extensionben más út ugyanannak a célnak az elérésére?
• Vagy csupán a felhasználói felület változott meg?

Csak ha ezek a kérdések megválaszolódtak, beszélünk technikai megoldásokról.

Miért szinte mindig az aktuális extension-verzióra építünk

Egy döntést azonban nagyon tudatosan hozunk meg. Ha egy extensiont aktívan karbantartanak, alapvetően az aktuális támogatott verziót használjuk.

Nem azért, mert az új verziók automatikusan jobbak lennének, hanem mert úgy gondoljuk, hogy egy frissítésnek nem csupán a mai projektet kell megoldania. A platformot az elkövetkező évekre is karbantarthatóvá kell tennie.

Egy aktívan karbantartott extension a TYPO3-mal együtt fejlődik tovább.

• Biztonsági frissítéseket kap.
• Új PHP-verziók támogatottak.
• A hibák javításra kerülnek.
• Új igények épülnek be.

Aki tudatosan e fejlődés ellen dönt, gyakran egy rövid távú problémát old meg, miközben egy jelentősen nagyobbat teremt a következő frissítéshez.

Mikor van mégis értelme az egyedi kódnak

Természetesen vannak helyzetek, amikor egy hiányzó funkció üzletileg kritikus. Ekkor felmerül a kérdés, hogy szülessen-e egyedi kód.

A válaszunk itt sem alapvető igen, sem alapvető nem. Az egyedi kódot nem tekintjük vereségnek. De alapértelmezett megoldásnak sem.

Ha egy funkciót magunk fejlesztünk le, akkor tudatosan tesszük. Nem azért, mert történetesen hiányzik egy új extension-verzióból, hanem mert az ügynökséggel és az ügyféllel közösen úgy döntöttünk, hogy ennek a funkciónak hosszú távú üzleti értéke van.

Ez döntő különbség. Mert ezzel az egyedi kód tudatos befektetéssé válik – és nem egy frissítésre adott spontán reakcióvá.

Van még egy második eset is

Nem minden extension fejlődik tovább. Különösen a régebbi TYPO3-projektekben újra és újra olyan bővítményekkel találkozunk, amelyek fejlesztése évekkel ezelőtt megszűnt.

Itt egészen más kérdés merül fel. Nem az, hogy „Melyik aktuális verziót használjuk?” Hanem az, hogy „Van-e egyáltalán jövője ennek az extensionnek?”

Ha nem létezik reális utód, és a funkció továbbra is nélkülözhetetlen, gyakran mi magunk korszerűsítjük az ilyen extensionöket. Ennek során azonban nem az a cél, hogy az eredeti maintainert helyettesítsük. A cél az, hogy egy meglévő üzleti funkciót hosszú távon megőrizzünk.

Ezt a döntést is tudatosan hozzuk meg. Nem automatikusan.

A jó frissítések jó döntésekből állnak

Talán épp ez a legfontosabb tanulság sok enterprise frissítésből.

A legnehezebb feladatok ritkán abban állnak, hogy egy API-t lecseréljünk vagy egy adatbázis-migrációt végrehajtsunk. Abban állnak, hogy a technikai lehetőségeket összhangba hozzuk a gazdasági és szakmai igényekkel.

Egy frissítés ezért a mi szemléletünkben sosem kizárólag technikai projekt. Mindig egyben termékdöntések sorozata is.

• Mely funkciók maradjanak meg?
• Melyek változhatnak meg?
• Mely befektetéseknek van értelme hosszú távon?
• Mely technikai adósság éri még meg – és melyik már nem?

Az eszközök nem tudják megválaszolni ezeket a kérdéseket. A checklisták sem.

Tapasztalatra van szükségük. És gyakran arra a bátorságra is, hogy elfogadjuk: bizonyos helyzetekben nincs tökéletes megoldás.

Mit tanultunk ezekből a projektekből

Sok TYPO3-frissítés után ma kevésbé hiszünk az általános érvényű szabályokban, mint néhány évvel ezelőtt. Annál inkább hiszünk viszont a jó döntési elvekben.

• Az aktívan karbantartott szoftver maradjon a lehető legaktuálisabb.
• Az üzletileg kritikus funkciók tudatos értékelést érdemelnek.
• Az egyedi kód stratégiai döntés legyen, ne spontán reakció.

És mindenekelőtt: minden technikai döntésnek figyelembe kell vennie azt az időszakot, amely a frissítés után kezdődik.

Mert egy enterprise frissítés tényleges sikere ritkán a go-live napján mutatkozik meg. A rákövetkező években mutatkozik meg, amikor a platform továbbra is karbantartható marad, és a jövőbeli változásokat nem nehezíti meg feleslegesen.