Proč může být chyba v mobilní aplikaci nákladnější než na webu
Chybu na webu lze po opravě nasadit centrálně a při další návštěvě se už použije nová verze. U mobilní aplikace stojí mezi opravou a zákazníkem distribuční kanál a rozhodnutí zařízení nebo člověka aktualizovat. Chybný release proto může zůstat v provozu i poté, co je oprava připravena.
Proč oprava nekončí novým buildem
Aktualizace v Google Play může podléhat kontrole a po zveřejnění se k uživatelům nedostane najednou. Někteří mají zapnuté automatické aktualizace, jiní aktualizují ručně nebo až po určité době. Při postupném nasazování dostane nový release nejprve pouze vybraná část uživatelů.
V provozu proto zůstává několik verzí aplikace současně. Více z nich může komunikovat se stejnými backendovými službami, nemusí však podporovat stejná pole, pravidla nebo způsob přihlášení. Oprava nové aplikace tak musí počítat i se staršími klienty.
Pokud tým po zjištění chyby zastaví rollout, omezí počet dalších instalací. Uživatelé, kteří už chybnou verzi mají, však potřebují opravnou aktualizaci nebo jiný způsob zmírnění problému. I proto je prevence před releasem hodnotnější než u produktu, který se aktualizuje na jediném serveru.
Jak snížit riziko před releasem
Testování rozdělujeme podle rychlosti a prostředí:
- rychlé jednotkové a integrační testy ověřují logiku při každé relevantní změně;
- krátká smoke sada projde nejdůležitější cesty na emulátoru;
- vybrané end-to-end scénáře ověří fyzická zařízení a podporované verze Androidu;
- před větším releasem se kontroluje instalace, aktualizace, přihlášení, hlavní funkce a platební tok v testovacím režimu.
Zařízení vybíráme podle používání produktu a rizika konkrétní funkce. Není nutné spouštět celou sadu na každém modelu. Důležitější je vědět, které kombinace pokrýváme a proč.
Testy zapojujeme do procesu tak, aby byl výsledek k dispozici před rozhodnutím o releasu. Při selhání uložíme diagnostická data, která dovoluje nástroj a interní pravidla: log, snímek, video nebo technický záznam kroků. Jejich vytváření je třeba nakonfigurovat; není automatické u každého řešení.
Ochranná opatření po nasazení
Testování neodhalí každou možnou chybu. Riziko proto snižuje také postupný rollout, sledování pádů a klíčových metrik, možnost rollout zastavit a zpětně kompatibilní API. U vhodných funkcí pomůže konfigurační přepínač, kterým se problematická část dočasně vypne bez nového buildu.
Google Play podporuje také výzvy k aktualizaci a mechanismy aktualizace přímo v aplikaci. Jejich použití je však třeba navrhnout podle důležitosti opravy a uživatelské zkušenosti, nikoli jako náhradu za prevenci.
Co tím získáte
Automatizované testy mohou v kontrolovaném prostředí odhalit část chyb v kritických cestách ještě před veřejným rolloutem. Takové chyby lze prověřit a opravit bez tlaku způsobeného problémem v produkci.
Postupné nasazení a monitoring mohou zkrátit reakci na problém, který se projeví až v provozu, a podle způsobu nasazení omezit počet dotčených uživatelů. Tato opatření neodstraňují všechna rizika, ale dávají týmu více podkladů pro rozhodnutí.
Další krok
Projděte poslední tři produkční chyby a u každé určete, která kontrola nebo provozní pojistka ji mohla odhalit či zmírnit. Z výsledku vytvořte krátký smoke seznam a pravidla pro rollout nejbližšího releasu. Pokud produkt obsahuje také webovou část, porovnejte proces s automatizací webových aplikací.