Releasedag i apputveckling: innebörd, steg och förberedelse
Releasedag (release day) — det planerade datumet för lansering av en ny version av en mobilapp, inklusive förberedelse av build, granskning i butik, staged rollout och övervakning. För iOS-appar börjar processen med att ladda upp builden till App Store Connect 24-48 timmar före det planerade releasedatumet på grund av den obligatoriska Apple-granskningen. För Android — bygga och ladda upp till Google Play Console, där granskningsprocessen vanligtvis tar 1-4 timmar. Enligt Apple Developer Guidelines (2025) klarar 90% av byggen granskningen inom 24 timmar. Staged rollout gör det möjligt att minimera påverkan om fel upptäcks efter publicering.
Huvudpunkter
- Release day — en rad åtgärder från att bygga builden till övervakning efter rollout
- Staged rollout — gradvis utrullning: 1%, 10%, 50%, 100%
- Smoke testing — slutlig kontroll av builden innan den skickas till butiken
- Rollback plan — i förväg förberett återställningsscenario vid kritiska fel
- Release retrospective — analys av processen efter att rollout är klar till 100%
Vad är en releasedag och hur man förbereder sig
Releasedag — är inte bara ögonblicket när man trycker på Publish-knappen. Det är en koordinerad process där utvecklare, QA, devops, produktchefer och ibland support deltar. Förberedelserna börjar 2-3 veckor före releasedagen: fastställande av scope, code freeze, regressionstestning, förberedelse av release notes och marknadsföringsmaterial. Ju noggrannare förberedelser, desto lugnare förlöper själva releasedagen.
Checklistan för förberedelser inför releasedagen omfattar: slutlig QA-körning (regression + smoke suite) på release-builden; kontroll av metadata i butikerna (namn, beskrivning, skärmbilder, keywords); avstämning av staged rollout-procent med produktchefen; förberedelse av rollback-plan (vilken tagg som ska återdeployas, hur lång tid det tar); meddelande till teamet och relaterade tjänster om den kommande releasen. Release checklist bör automatiseras via CI/CD — till exempel som ett GitHub Actions-arbetsflöde som kontrollerar alla punkter innan release-taggen skapas.
En viktig del av förberedelserna — blackout-period (period då deploy till produktion är förbjuden). Vanligtvis införs blackout 48 timmar före releasedagen och hävs 24 timmar efter en lyckad rollout på 100%. Detta förhindrar oavsiktliga deployar som skulle kunna störa releasen. Change freeze under blackout-perioden gäller för alla tjänster som är relaterade till releasen.
Förbereda builden: code freeze, taggning och bygge
24-48 timmar före releasedagen införs code freeze — fullständigt stopp för ändringar i koden. Utvecklarna övergår till att förbereda dokumentation och release notes. DevOps bygger release-builden från en fastställd tagg (t.ex. v2.6.0-rc1). Builden genomgår en komplett regression suite (automatiska + manuella tester). Om kritiska buggar hittas — åtgärdas de före code freeze eller så skjuts releasen upp. Release candidate (RC) — en build som har klarat QA och är redo att skickas till butiken.
Taggning i Git: en annoterad tagg skapas (git tag -a v2.6.0 -m "Release v2.6.0"). CI/CD-pipelinen bygger AAB (Android App Bundle) för Google Play och IPA (iOS App Store Package) för Apple App Store. Till builden bifogas: en fil med kontrollsummor (SHA256), changelog och en lista över kända problem (known issues). Reproducible builds — idealisk praxis där återuppbyggnad från samma tagg ger ett binärt identiskt resultat.
bash
# Release-pipeline — taggskapande och bygge
# Förutsätter att code freeze redan är aktiv
# Skapa en releasegren från develop
git checkout develop
git pull origin develop
git checkout -b release/v2.6.0
git push origin release/v2.6.0
# Code freeze: grenskyddsregler blockerar nya PR:ar
# Kör regressionssviten i CI/CD
./gradlew clean testReleaseUnitTest connectedReleaseTest
# Skapa en release-tagg efter lyckad QA
git tag -a v2.6.0 -m "Release v2.6.0: payment module, dark mode"
git push origin v2.6.0
# Bygg release-binären via CI/CD
# fastlane build_release producerar AAB + universell APK
fastlane build_releaseViktigt: version bump (uppdatering av version code och version name) görs före code freeze. Efter code freeze ändras inte versionen. För Android: versionCode — monotont ökande heltal; versionName — semantisk version (2.6.0). För iOS: CFBundleVersion (build number) och CFBundleShortVersionString (semantisk version). Versioning bör automatiseras i gradle/xcconfig.
Ladda upp till butiken och genomgå granskning
För iOS: builden laddas upp via Xcode, Transporter eller fastlane till App Store Connect. Efter uppladdningen genomgår builden en automatisk Apple-kontroll (processing), skickas sedan för manuell granskning. Genomsnittlig granskningstid — 24 timmar, men kan variera från 1 timme till 7 dagar beroende på Apple-granskarnas arbetsbelastning och compliance-krav. Expedited review — begäran om påskyndad granskning för kritiska buggfixar (tillgänglig högst en gång i månaden, inte garanterad).
För Android: builden laddas upp via Google Play Console. Google använder en kombinerad metod: automatisk testning (accessibility, malware, policy compliance) + selektiv manuell granskning. Genomsnittlig granskningstid — 1-4 timmar. Internal test track och Closed track möjliggör slutlig testning innan publicering i Production track. Rekommenderas: 1-2 dagar för Internal test → 1 dag för Closed beta → gradvis Production rollout.
För båda plattformarna är det kritiskt att kontrollera metadata innan builden laddas upp: appens namn, beskrivning (short + full), skärmbilder för varje supported device (iPhone 6.5", 5.5", iPad, Android phone, tablet), keywords (iOS) eller store listing experiments (Android). Ett fel i metadata kan försena granskningen med ytterligare en dag. App metadata bör vara översatt till alla språk som stöds.
Staged rollout: hur man rullar ut en release utan risk
Staged rollout (gradual rollout, staged deployment) — en strategi där den nya versionen blir tillgänglig för användarna inte omedelbart, utan stegvis. Ett typiskt schema för ett moget team: 1% av användarna (första 2-4 timmarna) → 10% (24 timmar) → 25% (24 timmar) → 50% (24 timmar) → 100%. Varje steg inkluderar övervakning av mätvärden och kontroll av att inga kritiska fel finns. Staged rollout — det främsta verktyget för att minimera risk vid releaser.
Google Play Console tillhandahåller inbyggd staged rollout: man kan ange procentandel användare och planera gradvis ökning. För iOS App Store Connect finns ingen sådan inbyggd funktion — staged rollout implementeras via Phased Release (automatisk ökning av täckning under 7 dagar med möjlighet att pausa) eller via server-side feature flags med geografisk distribution. Phased release i App Store Connect ger möjlighet att pausa releasen (Pause Release) om problem upptäcks.
Nyckelmått för övergång till nästa steg: crash-free rate (≥99.9% för den nya releasen), ANR rate (Android, ≤0.1%), error rate på backend API (≤0.5% 5xx), användarbetyg (inte lägre än föregående version), apdex score (≥0.94). Om något mätvärde överskrider gränsen — pausas rollouten tills orsakerna har klarlagts. Go/no-go gate vid varje steg — ansvar för release managern eller on-call-ingenjören.
Övervakning efter lansering: vad man ska titta på de första timmarna
De första 4 timmarna efter lanseringen — den mest kritiska tiden. Teamet övervakar crash rate (Sentry, Firebase Crashlytics, App Center), error rate 5xx på backend, custom events (lyckade betalningar, inloggningar, registreringar), användarbetyg i App Store och Google Play, omnämnanden i sociala medier (Twitter, Reddit). Övervakningsdashboarden bör vara förberedd i förväg och tillgänglig på en stor skärm på kontoret eller i en dedikerad Slack-kanal. Release dashboard — ett enda fönster för alla release-mätvärden.
Särskild uppmärksamhet — regressionsmätvärden: jämförelse av crash rate med föregående version för samma period. Om crash rate har ökat med mer än 0.1% — är detta en röd flagga som kräver omedelbar analys. Det är också viktigt att jämföra median- och p95-latens för viktiga API-endpoints: även utan krascher kan en fördröjning av svarstiden på 200ms signalera ett problem. Metric comparison (baseline vs current) automatiseras i Datadog eller Grafana.
Användarfeedback — inte mindre viktig än numeriska mätvärden. Under de första timmarna efter lanseringen lämnar användarna aktivt recensioner i butikerna och skriver till supporten. Buggar som inte fångats av testerna dyker snabbt upp i recensionerna. Team lead eller en utsedd QA-ingenjör övervakar recensioner var 30:e minut under de första 4 timmarna och klassificerar dem: false positive, known issue (redan på known issues-listan), new bug. New bugs P0/P1 — utlösare för att pausa rollouten.
Rollback: när och hur man återkallar en release
Rollback — återgång till den tidigare stabila versionen vid upptäckt av kritiska problem. Beslutet om rollback fattas av release managern tillsammans med tech leaden om: crash-free rate för den nya releasen sjunker under 99%, en dataläcka upptäcks, kritisk funktionalitet (betalningar, auktorisering) inte fungerar för >5% av användarna, eller butiken (App Store Review) har avvisat builden efter publicering. Rollback trigger bör definieras före releasen så att beslutet fattas baserat på fakta, inte känslor.
För Android: rollback i Google Play Console — stoppa staged rollout och växla till föregående version. Om den aktuella builden redan är på 100% av användarna — publicera den föregående versionen som en ny release. För iOS: via App Store Connect — Phased Release → Pause Release → släpp en ny version med korrigering (App Store tillåter inte återgång till föregående version). iOS rollback är mer komplicerat: utvecklaren måste bygga en ny build med revert-commits och genomgå granskningen igen.
Efter rollback går teamet över till incidentläge: root cause analysis, hotfix eller nästa release med korrigering, post-mortem. Rollback — är inte ett misslyckande, utan en standardprocedur. Team som aldrig har gjort en rollback märker troligen inte problemet, snarare än att de släpper felfria releaser. Rollback rate — en av DORA-måtten: högpresterande team gör rollback vid <10% av releaserna och återhämtar sig inom <1 timme.
Vanliga frågor
Vilken dag är bäst att släppa en mobilapp?
Bästa dagarna — tisdag, onsdag eller torsdag. Måndag — hög trafik från helgen, fredag — risk att gå in i helgen med en problematisk release. Undvik fredag: om ett problem upptäcks efter deploy kommer teamet att fixa det på helgen eller vänta till måndag.
Vad gör man om App Store Review avvisar builden?
Läs orsaken till avvisandet i Resolution Center, åtgärda och ladda upp builden igen. Vanliga orsaker: trasiga länkar, ofyllda fält, innehåll utan prenumeration (om det krävs), föråldrade skärmbilder. App Review rejection försenar releasen med 24-48 timmar, därför bör den första uppladdningen av builden ske 3-5 dagar före det planerade releasedatumet.
Vilken procentandel staged rollout är optimal för start?
För stora releaser (major changes) — 1%. För patch-releaser — 5-10%. Det första steget bör vara tillräckligt litet för att vid fel ska påverkan vara minimal, men tillräckligt stort för att få statistiskt signifikanta mätvärden. 1% för en app med 10 miljoner användare — 100 000 personer, tillräckligt för att upptäcka kritiska problem.
Behöver man ha en releasefest?
Release party (teamfirande) — valfritt, men bra för moralen. Det är bättre att ha det efter en lyckad rollout på 100%, inte vid tidpunkten för uppladdning av builden. Release celebration kan kombineras med en release retrospective för att diskutera vad som gick bra och vad som kan förbättras.
Vem ansvarar för beslutet „släppa eller skjuta upp”?
Ansvaret ligger på release managern (vanligtvis senior engineer eller tech lead). Beslutet fattas baserat på data från release dashboard, inte baserat på deadline. Release manager har befogenhet att skjuta upp releasen om mätvärdena inte klarar go/no-go gate.
Sammanfattning
- Releasedag — koordinerad process från code freeze till övervakning efter rollout
- Förberedelse — release candidate, QA-körning, kontroll av metadata, rollback-plan
- Staged rollout — 1% → 10% → 25% → 50% → 100% med go/no-go gate vid varje steg
- Övervakning — crash-free rate, ANR, error rate 5xx, användarbetyg de första 4 timmarna
- Rollback — standardprocedur vid fall av crash-free rate under 99%
- Kommunikation — meddelande till team och intressenter före och efter lansering
- Release retrospective — analys av processen efter att rollout är klar till 100%
Vi utvecklar en mobil applikation nyckelfärdigt
IT Sectr skapar iOS- och Android-applikationer för startups och företag sedan 2017. Vi ger dig råd och föreslår den bästa lösningen.
Läs också