Forfatter: Pål Berg, Promis Qualify
Apper er ikke bare apper.
Denne artikkelen tar kun for seg native apper. Release av web apper og hybrid apper behandles ikke her.
Det som er spesielt når man skal ha apper ut til folket, er at det ikke bare er ên release.
Som oftest så er det flere, da de fleste apper har både iOS-versjoner (iPhone) og Android-versjoner (Samsung, LG, Sony og alle de andre). Noen har sågar også en WindowsPhone-versjon. Appene spiller sammen med baksystemene, altså de delene av funksjonaliteten som ligger på servere.
Man kan dermed få alle mulige kombinasjonene av koordinerte releaser av alt fra én til alle av disse:
- ANDROID
- IOS
- BAKSYSTEMER
Det varierer hvor tett baksystemutviklerne jobber med app-utviklerne. Og hvor tett app-utviklerne på ên plattform jobber med app-utviklerne på de andre app-plattformene. I noen tilfeller kan f.eks. Android-appen “stikke avgårde” og få inn ny funksjonalitet lenge før iPhone-appen. Eller omvendt.
Det betyr, at selv om avhengigheten mellom app-plattformene ikke er stor, så vil det som regel være avgjørende at release av apper og baksystemer koordineres.
Koordinerte releaser
Ved koordinerte releaser av både apper og baksystemer er det mest hensiktsmessig at baksystemene rulles ut før nyeste app-versjon fordi:
- De nye appene kan ha avhengigheter til endringer eller ny funksjonalitet i baksystemene.
- Det oppdaterte baksystemet skal fungere med de app-versjonene som allerede er i omløp. Skulle det dukke opp alvorlige problemer under eller rett etter prod-releasen av baksystemet, så kan man utsette app-releasene til baksystemene har nådd ønsket tilstand. Dette kan være problemer med baksystemet som sådan eller kompabilitetsproblemer mot en eller flere av de eldre versjonene av appene.
- Appene testes mot den relevante versjonen av baksystemene. Det er avgjørende at den versjonen av baksystemet som appene er testet mot, ligger i prod når appene slippes. Man må derfor allerede når man planlegger testingen av appene, vite hvilke versjoner av baksystemene man skal forholde seg til.
- Man får litt tid til å teste ut de nye versjonene av app’ene i prod mot det nyeste baksystemet før app’ene gjøres tilgjengelige i app-butikkene. Heri inkludert oppgraderingstester. Man kan bl.a. involvere betagrupper. Betagrupper er et antall frivillige brukere som får prodversjon av appene litt før planlagt release.
Gradvis utrulling
Native apper rulles ut gjennom Google Play Store og Apple’s App Store. Dette kan gjøres gradvis:
- For Android ved at man først f.eks. tilgjengeliggjør den nye appen for 10% av brukerne, deretter de neste 40% dagen etter osv. Man har dermed mulighet til å stoppe utrullingen før alle har tilgang, hvis det skulle vise seg å være nødvendig.
- For iOS kan man ha gradvis utrulling i faser (phased release) til de som har på automatisk oppdatering. Det skjer etter et fast mønster, som starter på 1% første dag og via en tilnærmet dobling pr dag (1%-2%-5%-10%-20%-50%-100%) ender opp på 100% automatisk oppdatering i løpet av 7 dager. Den manuelle oppdateringen påvirkes ikke av dette, så alle vil kunne se den nye versjonen i App Store og kunne laste ned denne fra dag 1. Man kan sette den gradvise utrullingen på pause, men fortsatt vil manuell oppdatering være tilgjengelig.
For apper er det aldri snakk om tilbakerulling. Man kan i krisesituasjoner kun ta appen ut av app-butikken, og så fort som mulig komme med en ny og bedre versjon.
Når man planlegger releasedato så må man også ta høyde for at appen skal godkjennes av “butikksjefen” før den legges i Google Play Store og Apple’s App Store. Apple er noe mer rigide og deres godkjenningsprosess tar lenger tid, i verste fall opp mot en uke. Mens det for Google vanligvis tar 2 minutter.
Photo by yousef alfuhigi on Unsplash