Kiadás mindkét store-ba, dráma nélkül

Két store, két kultúra

Az Apple és a Google store-ja két különböző vérmérsékletű világ, és a kiadási folyamatnak mindkettőhöz igazodnia kell. Az Apple-nél emberek bírálnak: szigorúbbak, és néha egyszerűen van véleményük. Teljesen hétköznapi, hogy egy metaadat-apróság vagy egy nem elég egyértelmű előfizetési képernyő miatt jön a visszautasítás, ezért egy új app első beküldésére napokat érdemes betervezni, nem órákat. A Google review-ja gyorsabb és nagyrészt automatizált, cserébe az Android máshol kéri el az árát: a staged rolloutot neked kell kézben tartanod, az eszközparkot lehetetlen teljesen letesztelni, a szabályzatváltozások pedig határidővel érkeznek.

Ebből a gyakorlatban egy dolog következik: a store-ok elvárásait az első naptól termékkövetelményként kell kezelni. Adatvédelmi címkék, Data Safety-űrlap, kötelező fióktörlés, az előfizetés feltüntetésének szabályai – az a csapat, amelyik ezekkel beküldéskor szembesül, heteket veszít. Amelyik eleve ezekre tervez, semmit.

A release legyen unalmas

Az egészséges release az, amelyikről nincs mit mesélni – de ez az eseménytelenség nem magától jön, meg kell dolgozni érte. Amiből nálunk nem engedünk:

• —A CI buildeli mindkét platformot egy tagből – fejlesztői laptopról soha nem megy ki release; a store-okba egyetlen út vezet, a pipeline
• —Az automatizált tesztek engedik át vagy tartják vissza a release-t: unit és widget tesztek a pipeline-ban, a kritikus folyamatok a device farmon – ha piros, a tag nem megy tovább
• —Staged rollout alapból: a release először a felhasználók kis hányadához jut el, és a crash-monitorozás dönti el, mehet-e tovább
• —A remote config és a feature flagek elválasztják a deployt a bevezetéstől: a kód kikapcsolva megy ki, a funkciót akkor kapcsoljuk be, amikor mi akarjuk, és store-review nélkül ki is kapcsolhatjuk
• —A store-metaadatot ugyanúgy verziózzuk, mint a kódot: mindkét nyelv, mindkét store, a képernyőképek és a szövegek a repóban vannak, nem valakinek a fejében

A vészkijárat elve

A mobil legfontosabb különbsége a webhez képest, hogy egy release-t nem lehet azonnal visszahúzni. Egy rossz webes deployt percek alatt visszaállítasz; egy rossz appverzió viszont addig él a felhasználók telefonján, amíg ők nem frissítenek. Ez az aszimmetria mozgatja az egész fegyelmet: a staged rollout azt adja, hogy időben megállíthatod a bajt, a feature flag azt, hogy új kiadás nélkül kapcsolhatsz ki egy funkciót, a remote config pedig azt, hogy a bináris érintése nélkül hangolhatod a viselkedést.

Ezért is ér sokkal kevesebbet mobilon a „majd a következő release-ben javítjuk” mondat, mint bárhol máshol. A következő release egy teljes review-ciklusnyira van, és lesznek felhasználók, akik hónapokig nem telepítik. A vészkijáratoknak már az incidens előtt a helyükön kell lenniük.

A kiadási ritmus maga is feature

Aki ritkán ad ki, rosszul ad ki: minden release nagyra, kockázatosra és ijesztőre dagad, ettől pedig a csapat még ritkábban mer kiadni. A kör szerencsére fordítva is működik, és ez bárkinek elérhető: a kis, gyakori release-eknél minden diff átnézhető marad, minden visszalépés olcsó, minden incidens kicsi. Minden termékünknél arra törekszünk, hogy a release egy átlagos keddi rutinfeladat legyen, ne negyedévente egyszer bekövetkező esemény válságstábbal.

Amikor egy ügyfél kiadási fegyelmet vesz tőlünk, valójában ezt a ritmust veszi: azt a nyugalmat, hogy a fejlesztések folyamatosan érkeznek, és egyetlen release sem tudja elsüllyeszteni a terméket.