Releasedag in app-ontwikkeling: essentie, fases en voorbereiding
Releasedag (release day) — de geplande datum voor het uitbrengen van een nieuwe versie van een mobiele app, inclusief het voorbereiden van de build, review door de store, staged rollout en monitoring. Voor iOS-apps begint het proces met het uploaden van de build naar App Store Connect 24-48 uur voor de geplande releasedatum vanwege de verplichte Apple-review. Voor Android — het bouwen en uploaden naar Google Play Console, waar het reviewproces meestal 1-4 uur duurt. Volgens Apple Developer Guidelines (2025) doorloopt 90% van de builds de review binnen 24 uur. Staged rollout minimaliseert de impact als er na publicatie fouten worden ontdekt.
Belangrijkste punten
- Release day — geheel van maatregelen van het bouwen van de build tot monitoring na rollout
- Staged rollout — gefaseerde uitrol: 1%, 10%, 50%, 100%
- Smoke testing — laatste controle van de build voor verzending naar de store
- Rollback plan — vooraf voorbereid terugdraaiscenario bij kritieke fouten
- Release retrospective — analyse van het proces na voltooiing van rollout op 100%
Wat is een releasedag en hoe bereid je je voor
Releasedag — is niet alleen het moment van op de Publish-knop drukken. Het is een gecoördineerd proces waarbij ontwikkelaars, QA, devops, productmanagers en soms ondersteuning betrokken zijn. De voorbereiding begint 2-3 weken voor de releasedag: afstemmen van de scope, code freeze, regressietesten, voorbereiden van release notes en marketingmateriaal. Hoe grondiger de voorbereiding, hoe rustiger de releasedag zelf verloopt.
De checklist voor de voorbereiding op de releasedag omvat: finale QA-run (regression + smoke suite) op de release-build; controle van metadata in de stores (naam, beschrijving, screenshots, keywords); afstemmen van het staged rollout-percentage met de productmanager; voorbereiden van een rollback-plan (welke tag opnieuw deployen, hoe lang het duurt); het team en gerelateerde services informeren over de aanstaande release. Release checklist moet via CI/CD worden geautomatiseerd — bijvoorbeeld als een GitHub Actions-workflow die alle punten controleert voordat de releasetag wordt aangemaakt.
Een belangrijk onderdeel van de voorbereiding is de blackout-periode (periode waarin deploys naar productie verboden zijn). Meestal wordt de blackout 48 uur voor de releasedag ingesteld en 24 uur na succesvolle rollout op 100% opgeheven. Dit voorkomt accidentele deploys die de release kunnen verstoren. Change freeze tijdens de blackout-periode geldt voor alle services die met de release te maken hebben.
Build voorbereiden: code freeze, taggen en bouwen
24-48 uur voor de releasedag wordt code freeze ingesteld — volledige stopzetting van wijzigingen in de code. Ontwikkelaars schakelen over op het voorbereiden van documentatie en release notes. DevOps bouwt de release-build van een vastgestelde tag (bijv. v2.6.0-rc1). De build doorloopt een volledige regression suite (automatische + handmatige tests). Als er critical bugs worden gevonden — worden ze voor de code freeze opgelost of wordt de release uitgesteld. Release candidate (RC) — een build die QA heeft doorlopen en klaar is om naar de store te worden gestuurd.
Taggen in Git: er wordt een geannoteerde tag aangemaakt (git tag -a v2.6.0 -m "Release v2.6.0"). De CI/CD-pipeline bouwt AAB (Android App Bundle) voor Google Play en IPA (iOS App Store Package) voor Apple App Store. Bij de build wordt gevoegd: een bestand met checksums (SHA256), changelog en een lijst met bekende problemen (known issues). Reproducible builds — ideale praktijk waarbij herbouwen van dezelfde tag een binair identiek resultaat oplevert.
bash
# Release-pipeline — tag aanmaken en bouwen
# Gaat ervan uit dat code freeze al actief is
# Maak een releasebranch aan van develop
git checkout develop
git pull origin develop
git checkout -b release/v2.6.0
git push origin release/v2.6.0
# Code freeze: branchbeveiligingsregels blokkeren nieuwe PR's
# Voer de regressiesuite uit in CI/CD
./gradlew clean testReleaseUnitTest connectedReleaseTest
# Maak een releasetag aan na succesvolle QA
git tag -a v2.6.0 -m "Release v2.6.0: payment module, dark mode"
git push origin v2.6.0
# Bouw de release-binary via CI/CD
# fastlane build_release produceert AAB + universele APK
fastlane build_releaseBelangrijk: version bump (bijwerken van version code en version name) gebeurt voor code freeze. Na code freeze verandert de versie niet. Voor Android: versionCode — monotoon stijgend geheel getal; versionName — semantische versie (2.6.0). Voor iOS: CFBundleVersion (build number) en CFBundleShortVersionString (semantische versie). Versioning moet worden geautomatiseerd in gradle/xcconfig.
Uploaden naar de store en de review doorlopen
Voor iOS: de build wordt via Xcode, Transporter of fastlane naar App Store Connect geüpload. Na het uploaden doorloopt de build een automatische Apple-controle (processing), waarna deze wordt verzonden voor handmatige review. De gemiddelde reviewtijd is 24 uur, maar kan variëren van 1 uur tot 7 dagen, afhankelijk van de werklast van Apple-reviewers en compliance-vereisten. Expedited review — een verzoek om versnelde review voor kritieke bugfixes (maximaal één keer per maand beschikbaar, niet gegarandeerd).
Voor Android: de build wordt via Google Play Console geüpload. Google gebruikt een gecombineerde aanpak: automatische tests (accessibility, malware, policy compliance) + selectieve handmatige review. De gemiddelde reviewtijd is 1-4 uur. Internal test track en Closed track maken definitief testen mogelijk vóór publicatie in de Production track. Aanbevolen: 1-2 dagen voor Internal test → 1 dag voor Closed beta → geleidelijke Production rollout.
Voor beide platforms is het controleren van metadata vóór het uploaden van de build van cruciaal belang: app-naam, beschrijving (short + full), screenshots voor elk supported device (iPhone 6.5", 5.5", iPad, Android phone, tablet), keywords (iOS) of store listing experiments (Android). Een fout in metadata kan de review met een extra dag vertragen. App metadata moet worden gelokaliseerd in alle ondersteunde talen.
Staged rollout: hoe je een release zonder risico uitrolt
Staged rollout (gradual rollout, staged deployment) — een strategie waarbij de nieuwe versie niet direct, maar gefaseerd beschikbaar wordt voor gebruikers. Een typisch schema voor een volwassen team: 1% van de gebruikers (eerste 2-4 uur) → 10% (24 uur) → 25% (24 uur) → 50% (24 uur) → 100%. Elke fase omvat monitoring van metrieken en controle op afwezigheid van kritieke fouten. Staged rollout — het belangrijkste hulpmiddel voor risicominimalisatie bij releases.
Google Play Console biedt ingebouwde staged rollout: je kunt het percentage gebruikers instellen en een geleidelijke verhoging plannen. Voor iOS App Store Connect is er geen ingebouwde mogelijkheid — staged rollout wordt geïmplementeerd via Phased Release (automatische verhoging van het bereik gedurende 7 dagen met pauzemogelijkheid) of via server-side feature flags met geografische spreiding. Phased release in App Store Connect biedt de mogelijkheid om de release te pauzeren (Pause Release) bij het ontdekken van problemen.
Belangrijkste metrieken voor overgang naar de volgende fase: crash-free rate (≥99.9% voor de nieuwe release), ANR rate (Android, ≤0.1%), error rate op backend API (≤0.5% 5xx), gebruikersbeoordelingen (niet lager dan vorige versie), apdex score (≥0.94). Als een metriek de drempel overschrijdt — wordt de rollout gepauzeerd tot de oorzaken zijn opgehelderd. Go/no-go gate in elke fase — verantwoordelijkheid van de release manager of on-call engineer.
Monitoring na de release: waarop letten in de eerste uren
De eerste 4 uur na de release — de meest kritieke tijd. Het team monitort crash rate (Sentry, Firebase Crashlytics, App Center), error rate 5xx op de backend, custom events (succesvolle betalingen, logins, registraties), gebruikersbeoordelingen in App Store en Google Play, social media-vermeldingen (Twitter, Reddit). Het monitoringdashboard moet van tevoren zijn voorbereid en beschikbaar zijn op een groot scherm op kantoor of in een speciaal Slack-kanaal. Release dashboard — een enkel venster voor alle metrieken van de release.
Speciale aandacht — regressiemetrieken: vergelijking van crash rate met de vorige versie over een vergelijkbare periode. Als crash rate met meer dan 0.1% is gestegen — is dit een rode vlag die onmiddellijke analyse vereist. Ook is het belangrijk om de mediane en p95-latentie van belangrijke API-endpoints te vergelijken: zelfs zonder crashes kan een vertraging van de responstijd met 200ms wijzen op een probleem. Metric comparison (baseline vs current) wordt geautomatiseerd in Datadog of Grafana.
Gebruikersfeedback — minstens zo belangrijk als numerieke metrieken. In de eerste uren na de release laten gebruikers actief recensies achter in de stores en schrijven ze naar de support. Bugs die niet door tests zijn opgevangen, komen snel naar boven in recensies. De team lead of een aangewezen QA-engineer monitort recensies elke 30 minuten in de eerste 4 uur en classificeert ze: false positive, known issue (al op de known issues-lijst), new bug. New bugs P0/P1 — trigger om de rollout te pauzeren.
Rollback: wanneer en hoe een release terug te draaien
Rollback — terugkeer naar de vorige stabiele versie bij ontdekking van kritieke problemen. Het besluit tot rollback wordt genomen door de release manager samen met de tech lead als: de crash-free rate van de nieuwe release onder de 99% zakt, er een datalek wordt ontdekt, kritieke functionaliteit (betalingen, autorisatie) niet werkt voor >5% van de gebruikers, of de store (App Store Review) de build na publicatie heeft afgewezen. Rollback trigger moet voor de release zijn gedefinieerd, zodat het besluit op basis van feiten wordt genomen, niet op emotie.
Voor Android: rollback in Google Play Console — stoppen van staged rollout en overschakelen naar de vorige versie. Als de huidige build al op 100% van de gebruikers is — publicatie van de vorige versie als een nieuwe release. Voor iOS: via App Store Connect — Phased Release → Pause Release → uitbrengen van een nieuwe versie met de fix (App Store staat terugdraaien naar vorige versie niet toe). iOS rollback is complexer: de ontwikkelaar moet een nieuwe build maken met revert-commits en opnieuw door de review.
Na rollback gaat het team over in incidentmodus: root cause analysis, hotfix of volgende release met de fix, post-mortem. Rollback — is geen falen, maar een standaardprocedure. Teams die nog nooit een rollback hebben gedaan, merken het probleem waarschijnlijk niet op, in plaats van dat ze foutloze releases uitbrengen. Rollback rate — een van de DORA-metrics: hoogpresterende teams doen een rollback bij <10% van de releases en herstellen binnen <1 uur.
Veelgestelde vragen
Op welke dag kun je het beste een mobiele app releasen?
De beste dagen — dinsdag, woensdag of donderdag. Maandag — hoog verkeer na het weekend, vrijdag — risico om het weekend in te gaan met een problematische release. Vermijd vrijdag: als er na de deploy een probleem wordt ontdekt, zal het team dit in het weekend moeten oplossen of tot maandag moeten wachten.
Wat te doen als App Store Review de build heeft afgewezen?
Lees de afwijzingsreden in Resolution Center, corrigeer en upload de build opnieuw. Veelvoorkomende oorzaken: niet-werkende links, oningevulde velden, inhoud zonder abonnement (indien vereist), verouderde screenshots. App Review rejection vertraagt de release met 24-48 uur, daarom moet de eerste upload van de build 3-5 dagen voor de geplande releasedatum plaatsvinden.
Welk percentage staged rollout is optimaal om mee te beginnen?
Voor grote releases (major changes) — 1%. Voor patchreleases — 5-10%. De eerste fase moet klein genoeg zijn om bij een fout minimale impact te hebben, maar groot genoeg om statistisch significante metrieken te verkrijgen. 1% voor een app met 10 miljoen gebruikers — 100.000 mensen, voldoende om kritieke problemen te ontdekken.
Moet je een release party houden?
Release party (teamviering) — optioneel, maar goed voor het moraal. Het is beter om deze te houden na succesvolle rollout op 100%, niet op het moment van het uploaden van de build. Release celebration kan worden gecombineerd met een release retrospective om te bespreken wat goed ging en wat er verbeterd kan worden.
Wie is verantwoordelijk voor de beslissing „release of uitstellen”?
De verantwoordelijkheid ligt bij de release manager (meestal een senior engineer of tech lead). Het besluit wordt genomen op basis van gegevens van het release dashboard, niet op basis van de deadline. Release manager heeft de bevoegdheid om de release uit te stellen als metrieken de go/no-go gate niet passeren.
Samenvatting
- Releasedag — gecoördineerd proces van code freeze tot monitoring na rollout
- Voorbereiding — release candidate, QA-run, metadatacontrole, rollback-plan
- Staged rollout — 1% → 10% → 25% → 50% → 100% met go/no-go gate in elke fase
- Monitoring — crash-free rate, ANR, error rate 5xx, gebruikersbeoordelingen in de eerste 4 uur
- Rollback — standaardprocedure bij daling van crash-free rate onder 99%
- Communicatie — informeren van team en stakeholders voor en na de release
- Release retrospective — analyse van het proces na voltooiing van rollout op 100%
We ontwikkelen een mobiele applicatie turnkey
IT Sectr creëert sinds 2017 iOS- en Android-applicaties voor startups en bedrijven. We adviseren u en stellen de beste oplossing voor.
Lees ook