Miért automatizálunk minden értelmesen automatizálható lépést a TYPO3-frissítéseknél

Amikor ügynökségekkel nagyobb TYPO3-frissítésekről beszélünk, a beszélgetés eleinte szinte mindig technikai témák körül forog. Melyik TYPO3-verzió van használatban? Mely bővítményeket kell modernizálni? Mekkora az egyedi kód? Melyik PHP-verziót érdemes a jövőben használni?

Ezek a kérdések természetesen fontosak.

Belül azonban érdekes módon gyakran sokkal kevésbé foglalkoztatnak minket, mint egy másik kérdés, amely jellemzően csak több projekt után merül fel:

Miért is végzünk bizonyos munkákat újra meg újra kézzel?

Ez a kérdés elsőre meglepően banálisnak hangzik. Valójában az elmúlt években jobban megváltoztatta a munkamódszerünket, mint sok technikai újítás magában a TYPO3-ban.

Hiszen szinte minden nagyobb frissítés két, egymástól nagyon eltérő feladattípus keverékéből áll.

Az egyik oldalon olyan technikai döntések állnak, amelyek tapasztalatot, architekturális rálátást és az ügyféllel folytatott egyeztetést igényelnek. A másik oldalon számos visszatérő tevékenység van, amelyek eredményének minden alkalommal azonosnak kell lennie. Éppen e két terület megkülönböztetése ma számunkra az egyik legfontosabb eleme egy sikeres frissítési folyamatnak.

Az ismétlődő munka nem mérnöki probléma

Első frissítési projektjeink kezdetén sok lépést magától értetődően kézzel végeztünk el. Elemeztük a deprecation-naplókat, elindítottuk a frissítővarázslókat, módosítottuk a konfigurációkat, ellenőriztük a bővítményeket, adatbázis-migrációkat hajtottunk végre, és pontról pontra végigdolgoztuk a tesztlistáinkat.

Ez működött.

Minden újabb projekttel azonban furcsa érzés kezdett kialakulni.

Nem azért, mert a feladatok nehezek lettek volna.

Hanem mert észrevettük, hogy ugyanazokat a problémákat oldjuk meg újra meg újra.

A projektek persze különböztek a részletekben. Minden platform a maga architektúráját, egyedi üzleti logikáját és saját kihívásait hozta magával. Mégis sok technikai minta meglepően gyakran ismétlődött.

Bizonyos deprecationök újra meg újra felbukkantak.

A bővítmények hasonló módosításai több projektben is szükségessé váltak.

A deployment lépései szinte azonosan zajlottak.

És még a minőségbiztosítás során talált hibák közül is sok ugyanazokba a kategóriákba tartozott.

Egy idő után világossá vált számunkra, hogy ezeket a feladatokat már egyáltalán ne tekintsük tényleges fejlesztői munkának.

Folyamatproblémává váltak.

A tapasztalat ne maradjon az egyes fejlesztők fejében

Sok cégnél a tapasztalatot valami személyes dolognak tekintik.

Egy adott fejlesztő különösen jól ismer egy régi bővítménykoncepciót. Egy másik arra emlékszik, milyen buktatók merültek fel egy korábbi frissítésnél. Egy harmadik pedig pontosan tudja, milyen sorrendet kell betartani egy összetett deploymentnél.

Ez meglepően jól működik – mindaddig, amíg ugyanazok az emberek kísérnek minden projektet.

A mi szemszögünkből azonban ez strukturális kockázatot teremt.

Minél több tudás létezik kizárólag az egyes fejlesztők fejében, annál nehezebbé válik a projektek reprodukálható lebonyolítása.

Ezért ma igyekszünk minden visszatérő felismerést a folyamatba átültetni.

Néha ebből egy új Rector-szabály születik.

Néha bővíti a belső tudásbázisunkat.

Néha egy új szkript jön létre, vagy egy újabb pont a frissítési ellenőrzőlistánkon.

Néha pedig már egy rövid megjegyzés is elég a dokumentációnkban ahhoz, hogy ugyanaz a hiba a következő projektben fel se merüljön.

A döntő tényező itt nem az eszköz.

A döntő tényező az, hogy a tapasztalat lépésről lépésre a rendszer részévé válik.

Az automatizálás nem azt jelenti, hogy mindent automatikusan végzünk el

Ezen a ponton gyakran találkozunk egy félreértéssel.

Amint szóba kerül az automatizálás, könnyen az a benyomás keletkezik, hogy a lehető legtöbb tevékenységet teljesen eszközökkel szeretnénk helyettesíteni.

Pontosan ez nem a célunk.

Az automatizálás kiválóan alkalmas olyan feladatokra, amelyek eredménye egyértelműen meghatározott.

• Egy visszatérő adatbázis-migráció.
• Egy ismert API-transzformáció.
• Egy szabványosított deployment-lépés.
• Egy vizuális regresszió, amely megbízhatóan összehasonlítható.

Amint azonban szakmai döntésekre van szükség, ez az előny nagyon gyorsan véget ér.

Egy szkript nem tudja megítélni, hogy egy egyedi backend-funkció még tükrözi-e az ügyfél aktuális üzleti folyamatát.

Nem tudja eldönteni, hogy egy bővítményt jobb-e lecserélni vagy továbbfejleszteni.

És végképp nem tud egy product ownerrel arról vitázni, hogy egy adott funkció miért jött létre az elmúlt években.

Ezek a feladatok a jövőben is a tapasztalt fejlesztők felelőssége maradnak.

Éppen ezért nem tekintjük az automatizálást a szakértelem helyettesítőjének.

Sokkal inkább lehetőségként tekintünk rá, hogy a szakértőket mentesítsük a rutinmunkától.

Eszközeink sok projekt eredményei

Amikor látogatók látják az irodánkat vagy beszélgetnek a csapatunkkal, időnként a Legacy Updaterről vagy a belső Rector-szabályainkról kérdeznek.

Néha az a benyomás alakul ki, hogy ezek az eszközök voltak a folyamatunk kiindulópontja.

Valójában éppen fordítva történt.

Először jöttek a projektek, aztán a problémák – és csak ezután születtek meg az eszközök.

Erre jó példa a belső frissítési ellenőrzőlistánk.

Ma negyvennégy egyedi ellenőrzési pontot tartalmaz, és egy projektet az első helyi fejlesztői környezettől egészen a végső go-live-ellenőrzésig kísér. Az elején olyan kérdések állnak, mint a Git-hozzáférés, a friss adatbázis-dumpok vagy a telepítés helyi reprodukálhatósága. A végén tudatosan ellenőrizzük a látszólagos apróságokat is – például a 404-es és 403-as oldalakat, az átirányításokat, a robots-fájlokat vagy a sitemapet –, mert éppen ezek a részletek tűnnek fel gyakran elsőként egy élesítés után.

Egyik pont sem elméletben született.

Mindegyik azért létezik, mert egyszer valahol pontosan ott merült fel egy probléma.

Ugyanez igaz a Legacy Updaterünkre is.

Vagy a belső migrációs szkriptjeinkre.

Vagy számos apró segédeszközre, amelyeket a kívülállók valószínűleg sosem látnak.

Mindegyik valós projektekből származó konkrét tapasztalatok eredménye.

A jó folyamatok nem csak a sebességet javítják

Amikor az automatizálásról esik szó, szinte mindig először az időmegtakarításról beszélünk.

A sebesség természetesen számít.

A mi szemszögünkből azonban inkább mellékhatás.

A tényleges előny máshol rejlik.

Egy reprodukálható folyamat javítja a minőséget.

Ha egy deployment minden alkalommal ugyanazokat a lépéseket követi, csökken annak a valószínűsége, hogy közvetlenül a go-live előtt egy fontos pont feledésbe merül.

Ha a visszatérő kódtranszformációk automatizáltan zajlanak, kevesebb figyelmetlenségből fakadó hiba keletkezik.

És ha a vizuális regressziós tesztek minden nagyobb módosítás után automatikusan lefutnak, sok problémát egyáltalán nem is kell egy terjedelmes, kézi tesztfázis során felfedezni.

Ez nem csak a fejlesztési ráfordítást csökkenti.

A minőségbiztosítást is megváltoztatja.

Minél korábban válnak láthatóvá a hibák, annál olcsóbban javíthatók.

Ezért ma tudatosan fektetünk időt olyan dolgokba, amelyek a végfelhasználó számára eleinte láthatatlanok maradnak.

Ezek gyakran csak hetekkel vagy hónapokkal később térülnek meg.

Minden lezárt megbízás megváltoztatja a következőt

Talán éppen ez a gondolat különböztet meg minket leginkább a néhány évvel ezelőtti munkamódszerünktől.

Korábban egy frissítést akkor tekintettünk lezártnak, amint a platform sikeresen futott az új TYPO3-verzión.

Ma ezen a ponton gyakran egy második elemzés kezdődik.

• Mely felismeréseket fogjuk a jövőben újra használni ebből a projektből?
• Mely lépések kerültek feleslegesen sok időbe?
• Mely problémákat ismerhettünk volna fel korábban?
• A folyamat mely részeit kellene automatizálnunk vagy dokumentálnunk?

Egy projektet csak akkor tekintünk igazán lezártnak, ha ezekre a kérdésekre választ kaptunk.

Hiszen a tényleges célunk nem pusztán az, hogy egyetlen platformot sikeresen modernizáljunk.

A célunk az, hogy a következő frissítés egy árnyalattal jobb legyen az előzőnél.

Amit ebből tanultunk

Visszatekintve ma valószínűleg jelentősen másképp szerveznénk meg első frissítési projektjeinket.

Nem azért, mert az akkori megoldások rosszak lettek volna.

Hanem mert időközben megértettük, hogy a tartós minőség nem pusztán a jó fejlesztőkből fakad.

Akkor jön létre, ha a jó fejlesztők a tapasztalataikat folyamatokba, eszközökbe és közös szabványokba ültetik át.

Talán éppen ez írja le a fejlesztés és a mérnöki munka közötti különbséget.

A fejlesztés egy konkrét problémát old meg.

A mérnöki munka gondoskodik arról, hogy ugyanazt a problémaosztályt a jövőben már ne kelljen ugyanúgy megoldani.

És éppen ezért fektetünk ma legalább annyi energiát a folyamatainkba, mint magába a kódba.