A Petadev működő mobilalkalmazások karbantartását, hibajavítását és a hozzájuk kapcsolódó háttérrendszerek üzemeltetését is vállalja. Saját fejlesztésű és más csapattól átvett appokkal egyaránt foglalkozunk. Az együttműködés elején felmérjük a rendszert, majd egyeztetjük a feladatokat, a felelősségeket és a támogatás feltételeit.
- Frissítések
- Hibajavítás
- Monitoring
- Áruházkezelés
- Új funkciók
30+ app
React Native-ben kiadott alkalmazás
2022 óta
folyamatosan fejlesztett és üzemeltetett Trinity Guard
iOS + Android
frissítések és áruházi kiadások
Mikor érdemes megkeresned minket?
- Az app működik, de nincs kijelölt csapat a frissítésekre és a hibák kivizsgálására.
- Régi React Native- vagy Expo-verzióra épül és szeretnéd felmérni a frissítés feladatait.
- Változott az operációs rendszer, egy áruházi követelmény vagy az apphoz kapcsolódó külső szolgáltatás.
- Bizonytalan, ki felel a backendért, a szerverért, a mentésekért és az alkalmazás kiadásáért.
- Fejlesztőváltás előtt állsz és szeretnéd megismerni az átvétel technikai feltételeit. Erről részletes útmutatót is írtunk.
A kiinduló állapot határozza meg, hogy először hibát kell javítani, elmaradt frissítéseket kell pótolni, vagy már kialakítható a rendszeres támogatás.
Milyen feladatokat egyeztetünk a karbantartáshoz?
A mobilalkalmazás frissítése
Áttekintjük az alkalmazás keretrendszerét, függőségeit és a platformokhoz kapcsolódó beállításait. A szükséges frissítés után ellenőrizzük az érintett folyamatokat és előkészítjük az új verzió kiadását. Egy React Native-frissítésnél a JavaScript-csomagok mellett az iOS- és Android-projektben is lehetnek módosítandó részek.
Áruházi kiadások és követelmények
Kezeljük az App Store-ba és a Google Playre kerülő verziókat, a tesztkiadásokat és az áruházi beállításokat. A frissítés akkor is szükségessé válhat, ha az appon semmi nem változott: a Google Play évente megemeli, milyen Android-verziót kell céloznia az új alkalmazásoknak és frissítéseknek, az Apple pedig rendszeresen előírja, hogy a feltöltött buildek friss Xcode- és SDK-verzióval készüljenek. Ezeket a határidőket figyeljük, hogy az app frissíthető maradjon az áruházakban.
Hibák feltárása és javítása
Először megvizsgáljuk, mikor és milyen körülmények között jelentkezik a probléma. A készülék típusa, az app verziója, a hálózat vagy egy külső szolgáltatás állapota is számíthat. A javítás után az érintett működést és a hozzá kapcsolódó fontos folyamatokat is ellenőrizzük.
A backend és az infrastruktúra feladatai
A támogatás része lehet a háttérszolgáltatások, az adatbázis és a kiszolgálói környezet kezelése. Külön egyeztetjük, mit figyel a rendszer, hová érkeznek a riasztások és ki intézkedik probléma esetén. A tárhely vagy felhőszolgáltatás díja és az üzemeltetési munka külön tétel.
Mentések és helyreállítás
Rögzítjük, milyen adatokról kell mentés, hol tárolható és milyen helyreállítási elvárásokhoz kell igazodnia. A megállapodásban tisztázzuk a mentések ellenőrzésének és a visszaállítás kipróbálásának felelősét, valamint a feladatok ütemezését.
Új igények kezelése
Az új funkciókat külön becsüljük és ütemezzük. Így a meglévő működés fenntartása és a termék bővítése követhető marad és egy nagyobb fejlesztési kérés költsége sem keveredik a rendszeres karbantartáséval.
Saját tapasztalat: a Trinity Guard működtetése
- 2022 vége óta
- Mobilapp, web, backend és infrastruktúra
- 3 elkülönített környezet
A Trinity Guard fejlesztésében 2022 vége óta veszünk részt. A mobilalkalmazás, a webes felület és a backend mellett az infrastruktúrával és a folyamatos továbbfejlesztéssel is foglalkozunk.
A rendszer három elkülönített környezetben fut: két AWS-régióban és egy budapesti dedikált szerveren. A környezetek saját alkalmazásadatokkal működnek, a frissítéseket régiónként vezetjük be. Ez konkrét üzemeltetési feladatokat jelent és nem azonos egy automatikusan egymás helyére lépő, közös adatbázisú rendszerrel.
Hogyan kezdődik a támogatás?
1Megismerjük az alkalmazást. Átbeszéljük a működését, a jelenlegi problémákat és azt, mely folyamatok kritikusak az üzlet számára.
2Áttekintjük a technikai állapotot. Megnézzük a forráskódot, a verziókat, a háttérrendszert, az integrációkat és az elérhető dokumentációt. Tisztázzuk, hogyan készíthető tesztverzió és hogyan adható ki új alkalmazásverzió.
3Meghatározzuk a szükséges első lépéseket. Különválasztjuk az átvételhez vagy stabilizáláshoz szükséges munkát a későbbi rendszeres feladatoktól. Ha hiányoznak hozzáférések vagy lényeges információk, előbb ezek rendezésére van szükség.
4Megállapodunk a támogatás kereteiben. Rögzítjük a vállalt feladatokat, az ügyfél és a fejlesztőcsapat felelősségeit, a hibabejelentés módját és az elszámolást.
5A megállapodás szerint kezeljük a változásokat. A javítások és frissítések előtt figyelembe vesszük a várható hatást, a tesztelési igényt és az élesítés feltételeit. Az új üzleti igényekhez külön fejlesztési terv készülhet.
Mit rögzítünk az együttműködés előtt?
Mely rendszerek tartoznak hozzánk?
Mobilapp, backend, adatbázis, infrastruktúra és külső integrációk közül pontosan mely elemek.
Mikor és hogyan érhető el a támogatás?
Kapcsolattartás, támogatási időszak, sürgősségi kategóriák és vállalható reakcióidő.
Mi számít sürgősnek?
Például teljes kiesés, bevételt érintő hiba vagy kisebb felületi probléma.
Mit fedez a díj?
Rendszeres feladatok, eseti munkák, külön árazott fejlesztések és külső szolgáltatói költségek.
Ki kezeli a hozzáféréseket?
Forráskód, áruházi fiókok, felhő, domain és integrált szolgáltatások jogosultságai.
Hogyan történik a kiadás?
Tesztelés, jóváhagyás, telepítés és szükség esetén a helyreállítás lépései.
A karbantartási díjat a rendszer állapota és a vállalt támogatás alapján lehet meghatározni. A reakcióidő a bejelentésre adott válaszra vonatkozik, a megoldás ideje a hiba okától és a szükséges beavatkozástól is függ.
Legyen egyértelmű, ki felel az alkalmazásod működéséért
Írd meg, melyik alkalmazás támogatásához keresel partnert és mi indította el a keresést: egy konkrét hiba, elmaradt frissítések vagy hosszú távú együttműködés. Átbeszéljük, mit kell felmérni ahhoz, hogy meghatározható legyen a következő lépés.
Új termék fejlesztéséhez a mobilalkalmazás-fejlesztési szolgáltatásunkat nézd meg. Ha előbb az üzemeltetés alapjait szeretnéd megismerni, olvasd el az appok üzemeltetéséről szóló útmutatónkat.
Gyakori kérdések a mobilapp-karbantartásról
Csak akkor, ha erről külön megállapodtunk. A backend működtetése és a telefonra telepített alkalmazás karbantartása eltérő feladat. Az együttműködésben mindkettőnek meg kell nevezni a felelősét.
Az operációs rendszerek, a fejlesztői csomagok és a kapcsolódó szolgáltatások változhatnak. Emiatt egy változatlan funkciójú alkalmazásban is szükség lehet módosításra. A feladatot az alapján érdemes meghatározni, hogy az adott változás ténylegesen hogyan érinti a terméket. Mi annak a híve vagyunk, hogy felesleges teendő nélküli üzemeltetésért nem kell egy startupnak fizetnie rendszeresen, tehát csak projekt alapon végzünk fejlesztéseket üzemeltetés keretein belül, előre egyeztetett árakkal.
Nem feltétlenül. Más következménye lehet egy új verzió beküldését érintő feltételnek és egy tényleges működési hibának. A figyelmeztetés szövegét, határidejét és az alkalmazás állapotát együtt kell megvizsgálni.
Ez a hiba okától és a szerződés feltételeitől függ. A vállalt specifikációtól eltérő saját megvalósítás javítása, egy külső rendszer változásának követése és egy új funkció fejlesztése különböző feladat. A besoroláshoz előbb meg kell ismerni a probléma okát. Átvett alkalmazásnál a saját munkánkra vállalunk garanciát, a meglévő kódra akkor, ha az együttműködés szerződéssel és célzott kódátnézéssel indul, a szerződésben rögzített részekre és feltételekkel.
Az alkalmazás áruházi linkje, rövid leírása és a jelenlegi probléma jó kiindulópont. Ha ismert, írd meg a technológiát, az utolsó frissítés idejét és azt is, elérhető-e a forráskód, illetve az előző fejlesztő. Jelszavakat és hozzáférési kulcsokat ne küldj az ajánlatkérő űrlapon.