E-napló: gyakori frissítések több alkalmazást összehangolva

Az e-építési napló összetett rendszere több alkalmazást takar, tucatnyi szoftverkörnyezetben működő, majdnem húsz különböző modul-alkalmazást használ, így ezek verziófrissítése nem kis feladat. Az élesítést ezért a rendszer fejlesztésén dolgozó scrum csapat nem egyszerre végzi a számos alkalmazásban és modulban, hanem sorban egymás után, minden lépésnél a lehető leggondosabban eljárva.

A Lechner Tudásközpont a fejlesztések során agilis módszertant alkalmaz, amelynek jellemzője, hogy a felhasználói igényeket folyamatosan nyomon követve ciklikus jelleggel pontosítja a funkciókat, így gyorsan tud reagálni a felmerülő felhasználói elvárásokra. Ennek következtében rendszeresek a verziófrissítések, ezek során új funkciókat építenek be az alkalmazásokba vagy technológiai javításokat végeznek el. A módszer a felhasználók elégedettségére is hatással van, mert ők használat közben folyamatosan megtapasztalhatják az igények kiszolgálását célzó fejlesztések aktuális eredményeit. Mindez kölcsönösen működik, hiszen a fejlesztők számára is motiváló, ha szinte azonnal láthatják munkájuk eredményét.

Az elektronikus építési napló elnevezés tulajdonképpen nem egyetlen alkalmazást takar, hanem a sajátos építménytípusokat is kezelő rendszerek közötti – a különböző jogszabályi előírások miatt – kötelező eltérések és a demó, illetve tesztelői verziók miatt több mint tízféle szoftverkörnyezetben és adatbázisban működő, közel 20 modulról, illetve alkalmazásról beszélhetünk. Ezek verziófrissítése, a kódbázisok, az adatbázis-konzisztenciák összehangolása, majd mindezek tesztelése nem kis feladat. A verziófrissítési eseményekre való felkészülés önmagában napokat vesz igénybe, és maga az élesítés sem egyszerre történik a számos alkalmazásban, hanem sorban egymás után, minden lépésnél gondosan figyelve arra, hogy esetleges hiba esetén az eredeti verziók visszaállíthatóak legyenek, a javítás gyorsan le tudjon zajlani – mondta el Hülber Attila, az e-napló product ownere. A csapat számára mindig nagy élmény, amikor egy-egy élesítés megtörténik, hiszen a munkájuk eredménye tulajdonképpen ekkor válik kézzelfoghatóvá, ekkor kerül megmérettetésre a megelőző hosszú időszak fejlesztési tevékenysége. Úgy gondolják, hogy nem szerénytelenség, ha büszkék az eddig elért eredményeikre, az élesítések zökkenőmentességére. 

A távlati cél az, hogy az élesítések non-event módon, vagyis a rendszer leállása nélkül játszódjanak le, ahogy erre a Lechner egy másik szakrendszere, az ÉTDR már képes is. Jelenleg az e-napló fejlesztői elvileg ehhez már elég közel állnak, 5–15 percre van szükségük a friss verzióra történő átváltáshoz. Ennek ellenére az élesítéseknél tesztelés céljából másfél órás leállásokat iktatnak be, mivel a felhasználói szokások itt teljesen mások, így fontosabb az esetleges hibák kiszűrése, mint a gyorsaság. Az elektronikus építési napló felhasználói elsősorban kivitelezők, akiknek minden nap éjfélig kell az aznapi történéseket rögzíteniük. A logok tanulsága szerint ebédidőben használják legkevésbé a rendszert, ekkor a leállás – természetesen előzetes, három nappal korábbi értesítéssel – nem okoz különösebb gondot. 

A másfél órás időtartam lehetne akár kevesebb is, azonban pillanatnyilag nem ennek a rövidítése az elsődleges cél, hanem hogy a rendelkezésre álló idő alatt minél több tesztet tudjanak elvégezni. Ennek érdekében automatikus tesztrobotot alkalmaznak, ami 1 perc alatt több nap manuális tesztelési munkájával egyenértékű teljesítményt tud nyújtani. Amennyiben hibát észlelnek, azt lehetőség szerint azonnal kijavítják, illetve megnézik, hogy hány felhasználót érint. Kritikus jellegű, sokakat érintő és gyorsan nem megoldható probléma esetén az e-közmű scrum csapatának protokollja szerint akár vissza is állhatnak az előző verzióra, ami az elmúlt hét évben eddig egyetlen egy alkalommal fordult elő, de adott esetben inkább vállalják a visszalépés ódiumát, minthogy a felhasználókat adatvesztés érje, vagy bármilyen jelentősebb hiba maradjon a rendszerben. Ez az élesítési metódus az adott felhasználói szokások mellett jól működik. 

Az élesítést – a tesztrendszer hibátlan működését követően – mindig az általános eljárásokat támogató támogató e-napló alkalmazással kezdik. Bár logikusnak tűnhetne, hogy valamelyik kevesebb felhasználót érintő területen induljon el a folyamat, a gyakorlatban mégis ez a módszer bizonyult a leginkább célravezetőnek, ugyanis az esetleges hibák itt sokkal gyorsabban kiderülnek. Felmerülhet az a kérdés is, hogy miért nem a demó verzión próbálják ki először a változtatásokat, azonban ennek mindig meg kell egyeznie az élesben működő rendszerrel. A demó verziónak az a fő célja, hogy a felhasználók még a tényleges munka megkezdése előtt meg tudják ismerni a rendszert, másrészt a támogatásban résztvevő munkatársaknak is lehetőséget ad arra, hogy a felhasználók által jelzett hibákat itt megpróbálják rekonstruálni, és így pontosabb válaszokat, javaslatokat tudjanak adni.

Az e-napló mobil applikációja egyre nagyobb teret hódít, ma már több tízezer felhasználója van és a legtöbb funkció itt is elérhető. Ennek megfelelően a mobil alkalmazás verziófrissítéseit is a desktopos környezetben működőéhez ütemezik.

Az elektronikus építési napló 2013 óta üzemel, az eddigi összes felhasználóinak száma megközelíti a 300 ezret, naponta több tízezren használják az alkalmazást. A rendszer múltja a felhalmozódott tapasztalatok révén előnyt is jelent, de ugyanakkor nagy kihívás egy folyamatosan változó környezetben a működés feltételeit megteremteni és a korábbi adatokat megőrizni, a hozzáférhetőségüket biztosítani. Az e-naplót érintő jogszabályok ugyanis átlagosan féléves gyakorisággal módosulnak, a piaci környezet változásainak szükségszerű következményeként. 

Az elmúlt évek során több olyan, a fejlesztők által szoftverágnak vagy logikai ágnak elnevezett részegysége is kialakult a rendszernek, amelyek rövidebb ideig hatályban lévő, ma már nem érvényes jogszabályok alapján jöttek létre. Ezek kezelése az élesítések során különösen kritikus, mert bár gyakran csak kevés felhasználót érintenek, a hozzáférhetőségüket biztosítani kell. Hasonló, de már sokakat érintő kör az egyszerű bejelentéssel létrejövő épületek kategóriája, amely több tízezer építési naplót tartalmaz, és amelynél 2016 és 2019 között a bejelentés is az e-napló alkalmazásban történt. A verziófrissítések folyamán mindezek miatt nemcsak az aktuális, hanem a már nem aktív funkciókra is gondolniuk kell a fejlesztőknek. 

Az alkalmazást fejlesztő csapat 2017 végén vette át a rendszer továbbfejlesztését és 2018 januárjától agilis keretrendszerben folytatja a munkát. A scrum munkamódszerre jellemző product owner, scrum master szerepkörökben és a team – business analyst, frontend-, backend-, adatbázis- és mobilfejlesztő, designer, illetve üzemeltető – tagjai között a legkülönbözőbb korosztályokat találhatjuk meg. A használt programozási nyelv a Java, illetve a JavaScript, az új fejlesztések Angular platformon készülnek, az adatbázis-kezelés Postgres segítségével történik. 

A rendszer indulásától 2018-ig évente nagyjából egy verziófrissítés került ki az alkalmazásokba, illetve a köztes módosítások általában az elengedhetetlen hibajavításokból álltak. A scrum módszertan bevezetése óta ütemezetten, éves szinten nagyjából 6-8 verziófrissítés történik szinte az összes e-naplóval kapcsolatos alkalmazást érintően, amelyek során alkalmanként 5-10 új funkció is készül a felhasználói igények jobb kiszolgálása érdekében. Az esetleges hibák javításait tartalmazó kódok is ezen alkalmakkor élesednek. Ettől csak a működést akadályozó hiba kijavítása esetén térnek el, betartva ennek szigorú szabályrendszerét és a szükséges tájékoztatási kötelezettségeket. 

A felhasználók visszajelzéseinek beépítésére számos lehetőség áll rendelkezésre, ehhez egyrészt a felhasználói statisztikákat használják fel, másrészt – ami még fontosabb – a telefonon, a helpdesken, e-mailen, mobil applikáción keresztül érkező konkrét bejelentéseket. A felhasználói jelzésekkel, javaslatokkal kapcsolatban először megvizsgálják, hogy mi a probléma, mennyire jelentős, mennyi felhasználót érint, mennyi munkát igényel a kezelése. Az is egy fontos szempont, hogy a változtatás esetleg nem generálna-e több hibát, mint amennyit megold, illetve a felhasználók jelentős csoportja által már megszokott, megkedvelt megoldásokat is csak akkor érdemes újakkal felülírni, ha ennek komoly pozitív hozadéka van.