Kiadási nap az alkalmazásfejlesztésben: lényeg, szakaszok és felkészülés
Kiadási nap (release day) — a mobilalkalmazás új verziója kiadásának tervezett dátuma, beleértve a build előkészítését, az áruházi review-t, a staged rollout-ot és a monitorozást. iOS alkalmazások esetén a folyamat a build App Store Connect-be való feltöltésével kezdődik 24-48 órával a tervezett kiadási dátum előtt a kötelező Apple review miatt. Android esetén — a build elkészítése és feltöltése a Google Play Console-ba, ahol a review folyamat általában 1-4 órát vesz igénybe. A Apple Developer Guidelines (2025) szerint a buildek 90%-a 24 órán belül átmegy a review-n. Staged rollout lehetővé teszi a hatás minimalizálását, ha a publikálás után hibákat fedeznek fel.
Főbb pontok
- Release day — intézkedések összessége a build elkészítésétől a rollout utáni monitorozásig
- Staged rollout — fokozatos bevezetés: 1%, 10%, 50%, 100%
- Smoke testing — a build végső ellenőrzése az áruházba küldés előtt
- Rollback plan — előre elkészített visszaállítási forgatókönyv kritikus hibák esetén
- Release retrospective — a folyamat elemzése a rollout 100%-os befejezése után
Mi a kiadási nap és hogyan készülj fel rá
Kiadási nap — nem csupán a Publish gomb megnyomásának pillanata. Ez egy összehangolt folyamat, amelyben fejlesztők, QA, devopsok, product managerek és néha a támogatás is részt vesz. A felkészülés 2-3 héttel a kiadási nap előtt kezdődik: a scope egyeztetése, code freeze, regressziós tesztelés, release notes és marketinganyagok előkészítése. Minél alaposabb a felkészülés, annál nyugodtabban telik maga a kiadási nap.
A kiadási napra való felkészülés ellenőrzőlistája tartalmazza: végső QA futtatás (regression + smoke suite) a kiadási builden; metaadatok ellenőrzése az áruházakban (név, leírás, képernyőképek, keywords); a staged rollout százalékának egyeztetése a product managerrel; a rollback terv előkészítése (melyik taget kell újratelepíteni, mennyi időt vesz igénybe); a csapat és a kapcsolódó szolgáltatások értesítése a közelgő kiadásról. Release checklist automatizálni kell CI/CD-n keresztül — például GitHub Actions workflow formájában, amely a kiadási tag létrehozása előtt ellenőrzi az összes pontot.
A felkészülés fontos eleme — blackout időszak (amikor a telepítés éles környezetbe tilos). Általában a blackout 48 órával a kiadási nap előtt lép életbe, és 24 órával a sikeres 100%-os rollout után oldódik fel. Ez megakadályozza a véletlen telepítéseket, amelyek megzavarhatnák a kiadást. Change freeze a blackout időszakban a kiadással kapcsolatos összes szolgáltatásra vonatkozik.
Build előkészítése: code freeze, tagelés és összeállítás
24-48 órával a kiadási nap előtt code freeze lép életbe — a kódváltoztatások teljes leállítása. A fejlesztők átváltanak a dokumentáció és a release notes előkészítésére. A DevOps összeállítja a kiadási buildet egy rögzített tagből (pl. v2.6.0-rc1). A build teljes regression suite-on (automatikus + manuális tesztek) megy keresztül. Ha critical bugokat találnak — azokat a code freeze előtt javítják, vagy a kiadást elhalasztják. Release candidate (RC) — olyan build, amely átment a QA-n és készen áll az áruházba küldésre.
Tagelés Git-ben: egy annotált tag jön létre (git tag -a v2.6.0 -m "Release v2.6.0"). A CI/CD pipeline összeállítja az AAB-t (Android App Bundle) a Google Play számára és az IPA-t (iOS App Store Package) az Apple App Store számára. A buildhez csatolva: ellenőrző összegek fájlja (SHA256), changelog és az ismert problémák listája (known issues). Reproducible builds — ideális gyakorlat, ahol ugyanabból a tagből történő újraépítés binárisan azonos eredményt ad.
bash
# Kiadási pipeline — tag létrehozása és buildelés
# Feltételezi, hogy a code freeze már aktív
# Hozz létre kiadási ágat a develop-ból
git checkout develop
git pull origin develop
git checkout -b release/v2.6.0
git push origin release/v2.6.0
# Code freeze: az ágvédelmi szabályok blokkolják az új PR-eket
# Futtasd a regressziós csomagot CI/CD-ben
./gradlew clean testReleaseUnitTest connectedReleaseTest
# Hozz létre kiadási taget sikeres QA után
git tag -a v2.6.0 -m "Release v2.6.0: payment module, dark mode"
git push origin v2.6.0
# Építsd meg a kiadási binárist CI/CD-n keresztül
# A fastlane build_release AAB-t + univerzális APK-t állít elő
fastlane build_releaseFontos: version bump (version code és version name frissítése) a code freeze előtt történik. Code freeze után a verzió nem változik. Android esetén: versionCode — monoton növekvő egész szám; versionName — szemantikus verzió (2.6.0). iOS esetén: CFBundleVersion (build number) és CFBundleShortVersionString (szemantikus verzió). Versioning automatizálni kell a gradle/xcconfig fájlban.
Feltöltés az áruházba és a review-n való átesés
iOS esetén: a build Xcode-on, Transporteren vagy fastlane-en keresztül kerül feltöltésre az App Store Connect-be. Feltöltés után a build automatikus Apple-ellenőrzésen (processing) megy keresztül, majd manuális review-ra kerül. Átlagos review idő — 24 óra, de az Apple reviewerek terheltségétől és a compliance követelményektől függően 1 órától 7 napig változhat. Expedited review — gyorsított review kérése kritikus hibajavításokhoz (havonta legfeljebb egyszer elérhető, nem garantált).
Android esetén: a build a Google Play Console-on keresztül kerül feltöltésre. A Google kombinált megközelítést alkalmaz: automatikus tesztelés (accessibility, malware, policy compliance) + szelektív manuális review. Átlagos review idő — 1-4 óra. Internal test track és Closed track lehetővé teszi a végső tesztelést a Production track-ben történő publikálás előtt. Ajánlott: 1-2 nap Internal test → 1 nap Closed beta → fokozatos Production rollout.
Mindkét platform esetében kritikus a metaadatok ellenőrzése a build feltöltése előtt: az alkalmazás neve, leírása (short + full), képernyőképek minden támogatott eszközhöz (iPhone 6.5", 5.5", iPad, Android phone, tablet), keywords (iOS) vagy store listing experiments (Android). Hiba a metaadatokban további egy nappal késleltetheti a review-t. App metadata lokalizálni kell az összes támogatott nyelvre.
Staged rollout: hogyan vezesd be a kiadást kockázat nélkül
Staged rollout (gradual rollout, staged deployment) — olyan stratégia, ahol az új verzió nem azonnal, hanem fokozatosan válik elérhetővé a felhasználók számára. Tipikus séma érett csapat esetén: a felhasználók 1%-a (első 2-4 óra) → 10% (24 óra) → 25% (24 óra) → 50% (24 óra) → 100%. Minden szakasz magában foglalja a mutatók monitorozását és a kritikus hibák hiányának ellenőrzését. Staged rollout — a kockázat minimalizálásának fő eszköze a kiadásoknál.
A Google Play Console beépített staged rollout-ot kínál: megadható a felhasználók százaléka és ütemezhető a fokozatos növelés. Az iOS App Store Connect-ben nincs ilyen beépített lehetőség — a staged rollout Phased Release-en (automatikus lefedettségnövelés 7 nap alatt, szüneteltetési lehetőséggel) vagy szerveroldali feature flageken keresztül, földrajzi elosztással valósítható meg. Phased release az App Store Connect-ben lehetőséget ad a kiadás szüneteltetésére (Pause Release) problémák észlelése esetén.
A következő szakaszba lépés kulcsfontosságú mutatói: crash-free rate (≥99.9% az új kiadásra), ANR rate (Android, ≤0.1%), error rate a backend API-n (≤0.5% 5xx), felhasználói értékelések (nem alacsonyabbak az előző verziónál), apdex score (≥0.94). Ha bármely mutató túllépi a küszöböt — a rollout szünetel az okok kiderítéséig. Go/no-go gate minden szakaszban — a release manager vagy az on-call mérnök felelőssége.
Monitorozás a kiadás után: mire figyelj az első órákban
A kiadás utáni első 4 óra — a legkritikusabb idő. A csapat monitorozza a crash rate-et (Sentry, Firebase Crashlytics, App Center), az error rate 5xx-et a backend-en, a custom eventeket (sikeres fizetések, bejelentkezések, regisztrációk), a felhasználói értékeléseket az App Store-ban és a Google Play-ben, a közösségi média említéseket (Twitter, Reddit). A monitorozási dashboard-ot előre el kell készíteni, és elérhetőnek kell lennie egy nagy képernyőn az irodában vagy egy dedikált Slack csatornán. Release dashboard — egyetlen ablak a kiadás összes mutatójához.
Különös figyelem — regressziós mutatók: a crash rate összehasonlítása az előző verzióval hasonló időszakban. Ha a crash rate több mint 0.1%-kal nőtt — ez piros zászló, amely azonnali elemzést igényel. Fontos továbbá a kulcsfontosságú API végpontok medián és p95 késleltetésének összehasonlítása: még crash-ek nélkül is, a válaszidő 200 ms-os lassulása problémát jelezhet. Metric comparison (baseline vs current) Datadog vagy Grafana segítségével automatizálható.
Felhasználói visszajelzés — nem kevésbé fontos, mint a numerikus mutatók. A kiadás utáni első órákban a felhasználók aktívan hagynak véleményeket az áruházakban és írnak a támogatásnak. A tesztek által el nem kapott hibák gyorsan felbukkannak a véleményekben. A team lead vagy a kijelölt QA mérnök 30 percenként monitorozza a véleményeket az első 4 órában és osztályozza azokat: false positive, known issue (már a known issues listán), new bug. New bugs P0/P1 — trigger a rollout felfüggesztésére.
Rollback: mikor és hogyan vond vissza a kiadást
Rollback — visszatérés az előző stabil verzióhoz kritikus problémák észlelése esetén. A rollback döntést a release manager hozza a tech lead-del közösen, ha: az új kiadás crash-free rate-je 99% alá esik, adatszivárgást észlelnek, kritikus funkció (fizetés, hitelesítés) nem működik a felhasználók >5%-ánál, vagy az áruház (App Store Review) elutasítja a buildet a publikálás után. Rollback trigger meg kell határozni a kiadás előtt, hogy a döntés tényeken alapuljon, ne érzelmeken.
Android esetén: rollback a Google Play Console-ban — a staged rollout leállítása és átváltás az előző verzióra. Ha a jelenlegi build már a felhasználók 100%-ánál van — az előző verzió publikálása új kiadásként. iOS esetén: App Store Connect-en keresztül — Phased Release → Pause Release → új verzió kiadása javítással (az App Store nem teszi lehetővé a visszatérést az előző verzióhoz). iOS rollback bonyolultabb: a fejlesztőnek új buildet kell készítenie revert-commitekkel, és újra át kell esnie a review-n.
Rollback után a csapat incidens módba lép: root cause analysis, hotfix vagy következő kiadás javítással, post-mortem. Rollback — nem kudarc, hanem szokásos eljárás. Azok a csapatok, amelyek soha nem végeztek rollbacket, valószínűleg nem veszik észre a problémát, nem hogy hibamentes kiadásokat adnának ki. Rollback rate — az egyik DORA mutató: a magas teljesítményű csapatok a kiadások <10%-ánál végeznek rollbacket és <1 óra alatt helyreállnak.
Gyakran ismételt kérdések
Melyik nap a legjobb mobilalkalmazást kiadni?
A legjobb napok — kedd, szerda vagy csütörtök. Hétfő — magas forgalom a hétvégéről, péntek — kockázat, hogy problémás kiadással megyünk a hétvégébe. Kerüld a pénteket: ha a telepítés után probléma derül ki, a csapat a hétvégén javítja vagy hétfőig vár.
Mi a teendő, ha az App Store Review elutasította a buildet?
Olvasd el az elutasítás okát a Resolution Center-ben, javítsd ki és töltsd fel újra a buildet. Gyakori okok: nem működő linkek, kitöltetlen mezők, előfizetés nélküli tartalom (ha szükséges), elavult képernyőképek. App Review rejection 24-48 órával késlelteti a kiadást, ezért az első build feltöltésének 3-5 nappal a tervezett kiadási dátum előtt kell megtörténnie.
Milyen százalékú staged rollout az optimális kezdésnek?
Nagy kiadásokhoz (major changes) — 1%. Patch kiadásokhoz — 5-10%. Az első szakasznak elég kicsinek kell lennie ahhoz, hogy hiba esetén a hatás minimális legyen, de elég nagynak ahhoz, hogy statisztikailag jelentős mutatókat kapjunk. 1% egy 10 millió felhasználós alkalmazásnál — 100 ezer ember, elegendő a kritikus problémák észleléséhez.
Kell-e release party-t tartani?
Release party (csapatünnepség) — opcionális, de hasznos a morál szempontjából. Jobb a sikeres 100%-os rollout után megtartani, nem a build feltöltésének pillanatában. Release celebration kombinálható a release retrospective-tel, hogy megbeszéljük, mi ment jól és mi javítható.
Ki felelős a „kiadás vagy elhalasztás" döntésért?
A felelősség a release manageren nyugszik (általában senior engineer vagy tech lead). A döntés a release dashboard adatain alapul, nem a határidőn. Release manager jogosult elhalasztani a kiadást, ha a mutatók nem mennek át a go/no-go gate-en.
Összefoglaló
- Kiadási nap — összehangolt folyamat a code freeze-től a rollout utáni monitorozásig
- Felkészülés — release candidate, QA futtatás, metaadatok ellenőrzése, rollback terv
- Staged rollout — 1% → 10% → 25% → 50% → 100% go/no-go gate-tel minden szakaszban
- Monitorozás — crash-free rate, ANR, error rate 5xx, felhasználói értékelések az első 4 órában
- Rollback — szokásos eljárás, ha a crash-free rate 99% alá esik
- Kommunikáció — a csapat és az érdekelt felek értesítése a kiadás előtt és után
- Release retrospective — a folyamat elemzése a rollout 100%-os befejezése után
Kulcsrakész mobilalkalmazást fejlesztünk
Az IT Sectr 2017 óta készít iOS és Android alkalmazásokat induló vállalkozásoknak és vállalkozásoknak. Tanácsot adunk, és a legjobb megoldást javasoljuk.
Olvassa el is