Hibakövetési rendszer kiépítése Sentry és Firebase Crashlytics segítségével

Hibakövetés Sentry Firebase online alkalmazásokhoz

A Hibakövetés Sentry Firebase akkor hasznos, ha egy alkalmazás hibái nem csak a felhasználói panaszokból derülnek ki, hanem mérhető adatokból is. A magánügyfélnek ilyenkor nem egy nagy fejlesztői csapatra van feltétlenül szüksége, hanem egy olyan szabadúszó fejlesztőre, aki be tudja állítani a hibajelentést, érti a naplókat, és világosan megmutatja, mi romlik el az alkalmazásban. Ez távoli munka, ezért a feladat leírása, a hozzáférések átadása, a tesztelés és az eredmény ellenőrzése is online történik.

Szerintem ez a munka sokszor alulértékelt. Egy kisebb alkalmazás tulajdonosa gyakran csak akkor foglalkozik vele, amikor már több felhasználó jelzi ugyanazt a hibát. Pedig a hibakövető rendszer pont arra való, hogy a gond előbb látszódjon. A Sentry és a Firebase Crashlytics más módon segít, de együtt is használhatóak. Az egyik részletesebb fejlesztői képet adhat, a másik erős mobilos összeomlásjelentést biztosíthat. A lényeg nem az eszköz neve, hanem az, hogy a hiba után legyen adat, ne találgatás.

Sentry Firebase hibakövetés célja

A Sentry Firebase hibakövetés célja, hogy az alkalmazás hibái rendszerezve jelenjenek meg. Látszódjon, mikor történt az összeomlás, milyen képernyőn jelent meg a gond, milyen eszközön futott az alkalmazás, és mennyire gyakori az eset. Ez különösen fontos akkor, ha az alkalmazás már éles használatban van. Egy ügyfél sokszor csak annyit lát, hogy valami nem működik. A fejlesztő viszont a hibajelentésből meg tudja nézni, hol kell beavatkozni.

Tapasztalatom szerint a legjobb eredmény akkor születik, ha a megrendelő nem csak azt írja le, hogy az app hibás, hanem megadja a fontos körülményeket is. Milyen rendszerben jelentkezik a probléma. Melyik verzióval. Milyen művelet után. Ha ezek mellé már működik a hibakövetés, a szakember gyorsabban halad. Ez nem jelenti azt, hogy minden hibát azonnal ki lehet javítani. De azt igen, hogy a munka kevésbé vakon történik.

A Qjob.hu felületén magánszemély is találhat olyan online fejlesztőt, aki hibakövető beállítást, Firebase ellenőrzést vagy Sentry integrációt vállal. Itt érdemes pontos feladatot adni, mert a hibakövetés nem egyetlen kattintás. Más a munka egy új alkalmazásnál, más egy régi kódbázisnál, és megint más akkor, ha már volt korábbi integráció, csak rosszul működik.

Hibakövetés árak online munkához

Az ár nagyban függ attól, hogy csak alapbeállítás kell, vagy a fejlesztőnek mélyebben kell vizsgálnia az alkalmazás működését. A túl olcsó munka ezen a területen gyakran gyengébb minőséget jelent, mert a szakember kihagyhatja a tesztelést, a jogosultságok ellenőrzését vagy a hibák értelmezését. Én azt látom, hogy egy tisztességes beállításnál az ár nem csak a kódolásért szól, hanem a gondolkodásért is. A naplók olvasása, a jelentések tisztítása és a felesleges zaj csökkentése mind része lehet a munkának.

Az olcsóbb feladatok általában akkor reálisak, ha az alkalmazás kódja rendezett, a hozzáférések megvannak, és a megrendelő pontosan tudja, mit szeretne. Ha a fejlesztőnek előbb meg kell értenie egy ismeretlen rendszert, akkor a díj nő. Ez nem feltétlenül rossz jel. Inkább azt mutatja, hogy a szakember nem ígér vakon.

Szakember választása hibakövetéshez

Hibakövetéshez olyan szakembert érdemes választani, aki nem csak beköt egy eszközt, hanem meg is tudja magyarázni az eredményt. A jó szabadúszó fejlesztő rákérdez az alkalmazás típusára, a használt keretrendszerre, a jelenlegi hibákra, a verziókezelésre és arra, hogy a megrendelő milyen adatokat szeretne látni. Nem baj, ha sokat kérdez. Ebben a munkában a túl kevés kérdés gyakran rosszabb jel.

Fontos a portfólió, de nem kell mindig látványos referencia. Itt sokszor többet ér egy rövid leírás arról, hogy a fejlesztő milyen hibakövető rendszerekkel dolgozott, milyen mobilos vagy webes környezetet ismer, és tud e érthető jelentést adni a talált problémákról. Ha a szakember csak általános alkalmazásfejlesztést említ, de nem beszél összeomlásjelentésről, eseménynaplókról vagy verziók szerinti hibakeresésről, akkor érdemes óvatosnak lenni.

Volt olyan eset, amikor egy ügyfél azt hitte, hogy az alkalmazása véletlenszerűen záródik be. A fejlesztő először beállította a Firebase Crashlytics jelentéseit, majd kiderült, hogy a hiba csak egy adott képernyőn és egy bizonyos adatbetöltés után jelentkezik. A javítás önmagában nem volt bonyolult, de a hiba megtalálása lett volna nehéz naplózás nélkül. Ez jól mutatja, hogy a hibakövetés nem dísz, hanem döntési alap.

Online munka menete és hozzáférések

Az online munka általában egy rövid egyeztetéssel indul. A megrendelő leírja, milyen alkalmazásról van szó, milyen rendszerben fut, és milyen hibákat tapasztal. Ezután jön a hozzáférések átadása. Ilyen lehet a forráskód tárhelye, a Firebase projekt, a Sentry fiók, a teszteléshez szükséges alkalmazásverzió vagy egy ideiglenes jogosultság. Én azt tartom biztonságosnak, ha a hozzáférés korlátozott, és a munka után visszavonható.

A szakember először ellenőrzi a meglévő beállításokat. Ha nincs hibakövetés, beköti az eszközt. Ha már van, megnézi, érkeznek e jelentések, helyes e a verziózás, és a hibák visszakereshetőek e. Ezután következhet a próbahiba, a tesztelés és az első jelentések értelmezése. A végeredmény lehet működő Sentry projekt, Firebase Crashlytics jelentés, rövid hibajegyzék, vagy javaslat a további javításokra.

A kommunikáció legyen egyszerű. Egy közös leírás, néhány képernyőkép, verziószám és tesztelési lépés sok félreértést megelőz. Sokan ott hibáznak, hogy csak annyit írnak, nem jó az app. Ebből a fejlesztő nem tud pontosan dolgozni. Jobb leírni, mit nyitott meg a felhasználó, mit várt, mi történt helyette, és ismételhető e a hiba.

Sentry Firebase beállítás minősége

A Sentry Firebase beállítás minősége nem attól jó, hogy sok adat gyűlik össze. Attól jó, hogy a hasznos adat látható, a felesleges zaj pedig kezelhető. Egy rosszul beállított hibakövető rendszer rengeteg ismétlődő vagy értelmezhetetlen jelzést küldhet. A megrendelő ilyenkor azt érzi, hogy van rendszer, mégsem kap választ. A fejlesztő feladata ezért az is, hogy a hibákat csoportosítsa, címkézze, és a fontos ügyeket előre tegye.

Minőségi munkánál a verziók is elkülönülnek. Látszik, hogy egy hiba melyik kiadásban kezdődött, és eltűnt e a javítás után. Mobilalkalmazásnál fontos lehet az eszköz típusa, a rendszerverzió, a memóriahelyzet és a felhasználói művelet. Webes alkalmazásnál számíthat a böngésző, a hálózati kérés, a felhasználói útvonal és a forráskép. Ezek nélkül a hiba sokszor csak egy homályos üzenet marad.

Szerintem akkor jó az átadás, ha a magánügyfél legalább alap szinten érti, mit lát a rendszerben. Nem kell fejlesztővé válnia. De tudnia kell, hol jelennek meg az új hibák, hogyan lehet megnézni a gyakoriságot, és mikor érdemes javítást kérni. Ez a tudás később pénzt takaríthat meg.

Tipikus hibák hibakövető beállításnál

Az egyik gyakori hiba, hogy a megrendelő csak a bekötést kéri, de nem kér ellenőrzést. Így lehet, hogy az eszköz technikailag működik, mégsem ad használható képet. A másik hiba a túl tág hozzáférés. Nem kell minden fiókot teljes jogosultsággal átadni. A harmadik gond az, amikor nincs világos cél. Más kell egy frissen induló alkalmazáshoz, és más egy olyan rendszerhez, ahol már sok felhasználó dolgozik naponta.

Gondot okozhat az is, ha a hibajelentések személyes adatokat tartalmaznak. A hibakövetés nem lehet adatgyűjtő szemetes. A szakembernek figyelnie kell arra, hogy érzékeny adatok ne kerüljenek feleslegesen a jelentésekbe. Ez nem csak jogi kérdés, hanem bizalmi kérdés is. Egy privát megrendelőnek is érdeke, hogy az alkalmazás tisztán és átláthatóan működjön.

Van egy másik, kevésbé látványos probléma. A fejlesztő beállítja a rendszert, de nem mondja el, mit kell figyelni. A megrendelő belép, lát sok hibát, majd nem tudja, melyik sürgős. Ilyenkor hasznos egy rövid magyarázat vagy hibaprioritási lista. Nem hosszú dokumentum kell. Csak érthető sorrend.

Hibakövetés eredménye és átadása

A hibakövetés eredménye akkor értékes, ha az ügyfél kézzelfogható választ kap. Működik e a jelentés. Milyen hibák látszanak. Melyik probléma ismétlődik. Melyik javítás sürgős. Milyen adat hiányzik még. Egy jó átadásban szerepelhet a beállított eszköz rövid leírása, a hozzáférések listája, a teszthibák eredménye, valamint néhány javaslat a következő lépésekre.

A Hibakövetés Sentry Firebase feladat végén nem az a cél, hogy a rendszer szépnek tűnjön. Az a cél, hogy az alkalmazás gazdája ne legyen kiszolgáltatva a véletlen panaszoknak. Ha a hiba megjelenik, legyen nyoma. Ha javítás történik, legyen ellenőrizhető. És ha új verzió kerül ki, látszódjon, hogy stabilabb lett e. Ez csendes munka, de sok későbbi vitát, találgatást és felesleges költséget megelőzhet.