Den vydání ve vývoji aplikací: podstata, fáze a příprava
Den vydání (release day) — plánované datum vydání nové verze mobilní aplikace, zahrnující přípravu sestavení, recenzi v obchodě, staged rollout a monitorování. Pro iOS aplikace proces začíná nahráním sestavení do App Store Connect 24-48 hodin před plánovaným datem vydání kvůli povinné recenzi Apple. Pro Android — sestavení a nahrání do Google Play Console, kde proces recenze obvykle trvá 1-4 hodiny. Podle Apple Developer Guidelines (2025) projde 90 % sestavení recenzí do 24 hodin. Staged rollout umožňuje minimalizovat dopad při odhalení chyb po publikaci.
Hlavní body
- Release day — soubor opatření od sestavení buildu po monitorování po rolloutu
- Staged rollout — postupné zavádění: 1 %, 10 %, 50 %, 100 %
- Smoke testing — konečná kontrola sestavení před odesláním do obchodu
- Rollback plan — předem připravený scénář vrácení při kritických chybách
- Release retrospective — analýza procesu po dokončení rollout na 100 %
Co je den vydání a jak se na něj připravit
Den vydání — není jen okamžik stisknutí tlačítka Publish. Je to koordinovaný proces, kterého se účastní vývojáři, QA, devops, product manageři a někdy podpora. Příprava začíná 2-3 týdny před dnem vydání: dohoda o rozsahu, code freeze, regresní testování, příprava release notes a marketingových materiálů. Čím důkladnější příprava, tím klidnější je samotný den vydání.
Kontrolní seznam přípravy na den vydání zahrnuje: závěrečné spuštění QA (regression + smoke suite) na release sestavení; kontrolu metadat v obchodech (název, popis, snímky obrazovky, keywords); dohodu o procentu staged rollout s product managerem; přípravu plánu rollback (který tag znovu nasadit, jak dlouho to bude trvat); upozornění týmu a souvisejících služeb o připravovaném vydání. Release checklist by měl být automatizován pomocí CI/CD — například jako GitHub Actions workflow, který před vytvořením release tagu zkontroluje všechny body.
Důležitý prvek přípravy — blackout period (období, kdy jsou nasazení do produkce zakázána). Obvykle se blackout zavádí 48 hodin před dnem vydání a ruší se 24 hodin po úspěšném rolloutu na 100 %. Tím se předchází náhodným nasazením, která by mohla vydání narušit. Change freeze v období blackout se vztahuje na všechny služby související s vydáním.
Příprava sestavení: code freeze, tagování a sestavení
24-48 hodin před dnem vydání se zavádí code freeze — úplné zastavení změn v kódu. Vývojáři přecházejí na přípravu dokumentace a release notes. DevOps sestaví release build z pevného tagu (např. v2.6.0-rc1). Build prochází kompletní regression suite (automatické + ruční testy). Pokud jsou nalezeny critical bugs — opraví se před code freeze nebo se vydání odloží. Release candidate (RC) — sestavení, které prošlo QA a je připraveno k odeslání do obchodu.
Tagování v Gitu: vytvoří se anotovaný tag (git tag -a v2.6.0 -m "Release v2.6.0"). CI/CD pipeline sestaví AAB (Android App Bundle) pro Google Play a IPA (iOS App Store Package) pro Apple App Store. K sestavení je přiložen: soubor s kontrolními součty (SHA256), changelog a seznam známých problémů (known issues). Reproducible builds — ideální praxe, při které opětovné sestavení ze stejného tagu poskytuje binárně identický výsledek.
bash
# Pipeline vydání — vytvoření tagu a sestavení
# Předpokládá, že code freeze je již aktivní
# Vytvořte větev vydání z develop
git checkout develop
git pull origin develop
git checkout -b release/v2.6.0
git push origin release/v2.6.0
# Code freeze: pravidla ochrany větve blokují nové PR
# Spusťte regresní sadu v CI/CD
./gradlew clean testReleaseUnitTest connectedReleaseTest
# Vytvořte tag vydání po úspěšné QA
git tag -a v2.6.0 -m "Release v2.6.0: payment module, dark mode"
git push origin v2.6.0
# Sestavte binární soubor vydání přes CI/CD
# fastlane build_release vytváří AAB + univerzální APK
fastlane build_releaseDůležité: version bump (aktualizace version code a version name) se provádí před code freeze. Po code freeze se verze nemění. Pro Android: versionCode — monotónně rostoucí celé číslo; versionName — sémantická verze (2.6.0). Pro iOS: CFBundleVersion (build number) a CFBundleShortVersionString (sémantická verze). Versioning by měl být automatizován v gradle/xcconfig.
Nahrání do obchodu a absolvování recenze
Pro iOS: sestavení se nahraje přes Xcode, Transporter nebo fastlane do App Store Connect. Po nahrání prochází sestavení automatickou kontrolou Apple (processing), poté je odesláno k ruční recenzi. Průměrná doba recenze — 24 hodin, ale může se lišit od 1 hodiny do 7 dnů v závislosti na vytížení recenzentů Apple a požadavcích na shodu. Expedited review — žádost o zrychlenou recenzi pro kritické opravy chyb (k dispozici maximálně jednou měsíčně, bez záruky).
Pro Android: sestavení se nahraje přes Google Play Console. Google používá kombinovaný přístup: automatické testování (accessibility, malware, policy compliance) + selektivní ruční recenze. Průměrná doba recenze — 1-4 hodiny. Internal test track a Closed track umožňují provést závěrečné testování před publikací do Production track. Doporučuje se: 1-2 dny na Internal test → 1 den na Closed beta → postupné Production rollout.
Pro obě platformy je kriticky důležité zkontrolovat metadata před nahráním sestavení: název aplikace, popis (short + full), snímky obrazovky pro každé podporované zařízení (iPhone 6.5", 5.5", iPad, Android phone, tablet), keywords (iOS) nebo store listing experiments (Android). Chyba v metadatech může zpozdit recenzi o další den. App metadata by měla být lokalizována do všech podporovaných jazyků.
Staged rollout: jak zavádět vydání bez rizika
Staged rollout (gradual rollout, staged deployment) — strategie, při které se nová verze zpřístupní uživatelům ne okamžitě, ale postupně. Typické schéma pro zralý tým: 1 % uživatelů (první 2-4 hodiny) → 10 % (24 hodin) → 25 % (24 hodin) → 50 % (24 hodin) → 100 %. Každá fáze zahrnuje monitorování metrik a kontrolu nepřítomnosti kritických chyb. Staged rollout — hlavní nástroj minimalizace rizika při vydáních.
Google Play Console poskytuje vestavěný staged rollout: lze určit procento uživatelů a naplánovat postupné zvyšování. Pro iOS App Store Connect taková vestavěná možnost není — staged rollout je realizován prostřednictvím Phased Release (automatické zvyšování pokrytí během 7 dnů s možností pozastavení) nebo pomocí server-side feature flags s geografickým rozložením. Phased release v App Store Connect dává možnost Pozastavit vydání (Pause Release) při zjištění problémů.
Klíčové metriky pro přechod do další fáze: crash-free rate (≥99.9 % pro nové vydání), ANR rate (Android, ≤0.1 %), error rate na backend API (≤0.5 % 5xx), hodnocení uživatelů (ne nižší než předchozí verze), apdex score (≥0.94). Pokud jakákoli metrika překročí práh — rollout je pozastaven do objasnění příčin. Go/no-go gate v každé fázi — odpovědnost release managera nebo on-call inženýra.
Monitorování po vydání: na co se dívat v prvních hodinách
První 4 hodiny po vydání — nejkritičtější doba. Tým monitoruje crash rate (Sentry, Firebase Crashlytics, App Center), error rate 5xx na backendu, custom events (úspěšné platby, přihlášení, registrace), hodnocení uživatelů v App Store a Google Play, zmínky na sociálních sítích (Twitter, Reddit). Monitorovací dashboard by měl být připraven předem a dostupný na velké obrazovce v kanceláři nebo na vyhrazeném Slack kanálu. Release dashboard — jednotné okno pro všechny metriky vydání.
Zvláštní pozornost — regresní metriky: porovnání crash rate s předchozí verzí za stejné období. Pokud crash rate vzrostl o více než 0.1 % — to je červená vlajka vyžadující okamžitou analýzu. Je také důležité porovnat medián a p95 latenci klíčových API endpointů: i bez crashů může zpomalení doby odezvy o 200 ms signalizovat problém. Metric comparison (baseline vs current) se automatizuje v Datadog nebo Grafana.
Zpětná vazba uživatelů — neméně důležitá než číselné metriky. V prvních hodinách po vydání uživatelé aktivně zanechávají recenze v obchodech a píší podpoře. Chyby nezachycené testy rychle vyplouvají v recenzích. Team lead nebo určený QA inženýr monitoruje recenze každých 30 minut v prvních 4 hodinách a klasifikuje je: false positive, known issue (již v seznamu known issues), new bug. New bugs P0/P1 — spouštěč pro pozastavení rollout.
Rollback: kdy a jak vrátit vydání zpět
Rollback — návrat k předchozí stabilní verzi při zjištění kritických problémů. Rozhodnutí o rollbacku přijímá release manager společně s tech leadem, pokud: crash-free rate nového vydání klesne pod 99 %, je zjištěn únik dat, kritická funkčnost (platby, autorizace) nefunguje pro >5 % uživatelů nebo obchod (App Store Review) odmítl sestavení po publikaci. Rollback trigger by měl být definován před vydáním, aby rozhodnutí bylo založeno na faktech, nikoli na emocích.
Pro Android: rollback v Google Play Console — zastavení staged rollout a přepnutí na předchozí verzi. Pokud je aktuální sestavení již na 100 % uživatelů — publikace předchozí verze jako nového vydání. Pro iOS: přes App Store Connect — Phased Release → Pause Release → vydání nové verze s opravou (App Store neumožňuje návrat k předchozí verzi). iOS rollback je složitější: vývojář musí sestavit nový build s revert commity a znovu projít recenzí.
Po rollbacku tým přechází do režimu incidentu: root cause analysis, hotfix nebo další vydání s opravou, post-mortem. Rollback — není selhání, ale standardní postup. Týmy, které nikdy neprovedly rollback, pravděpodobně problém nezaznamenávají, nikoli že vydávají bezchybná vydání. Rollback rate — jedna z DORA metrik: vysoce výkonné týmy provádějí rollback u <10 % vydání a zotavují se do <1 hodiny.
Často kladené otázky
Ve který den je nejlepší vydat mobilní aplikaci?
Nejlepší dny — úterý, středa nebo čtvrtek. Pondělí — vysoký provoz z víkendu, pátek — riziko vstupu do víkendu s problematickým vydáním. Vyhněte se pátku: pokud se po nasazení objeví problém, tým ho bude opravovat o víkendu nebo čekat do pondělí.
Co dělat, když App Store Review odmítne sestavení?
Přečtěte si důvod odmítnutí v Resolution Center, opravte a znovu nahrajte sestavení. Časté příčiny: nefunkční odkazy, nevyplněná pole, obsah bez předplatného (pokud je vyžadováno), zastaralé snímky obrazovky. App Review rejection zpožďuje vydání o 24-48 hodin, proto by první nahrání sestavení mělo být 3-5 dní před plánovaným datem vydání.
Jaké procento staged rollout je optimální pro začátek?
Pro velká vydání (major changes) — 1 %. Pro patch vydání — 5-10 %. První fáze by měla být dostatečně malá, aby v případě chyby byl dopad minimální, ale dostatečně velká, aby byly získány statisticky významné metriky. 1 % pro aplikaci s 10 miliony uživatelů — 100 tisíc lidí, dostatek pro odhalení kritických problémů.
Je třeba uspořádat release party?
Release party (týmová oslava) — volitelné, ale prospěšné pro morálku. Lepší je uspořádat ji po úspěšném rolloutu na 100 %, ne v okamžiku nahrávání sestavení. Release celebration lze spojit s release retrospective, aby se probralo, co šlo dobře a co lze zlepšit.
Kdo je odpovědný za rozhodnutí „vydat nebo odložit“?
Odpovědnost leží na release managerovi (obvykle senior engineer nebo tech lead). Rozhodnutí se přijímá na základě dat z release dashboard, nikoli na základě termínu. Release manager má pravomoc vydání odložit, pokud metriky neprocházejí go/no-go gate.
Shrnutí
- Den vydání — koordinovaný proces od code freeze po monitorování po rolloutu
- Příprava — release candidate, QA běh, kontrola metadat, plán rollback
- Staged rollout — 1 % → 10 % → 25 % → 50 % → 100 % s go/no-go gate v každé fázi
- Monitorování — crash-free rate, ANR, error rate 5xx, hodnocení uživatelů v prvních 4 hodinách
- Rollback — standardní postup při poklesu crash-free rate pod 99 %
- Komunikace — upozornění týmu a zainteresovaných stran před a po vydání
- Release retrospective — analýza procesu po dokončení rollout na 100 %
Vyvineme mobilní aplikaci na klíč
IT Sectr vytváří aplikace pro iOS a Android pro startupy a podniky od roku 2017. Poradíme vám a navrhneme nejlepší řešení.
Přečtěte si také