Der Release-Tag in der App-Entwicklung: Bedeutung, Phasen und Vorbereitung
Der Release-Tag (Release Day) ist das geplante Datum für die Veröffentlichung einer neuen Version einer mobilen App, einschließlich Build-Vorbereitung, Store-Überprüfung, gestaffeltem Rollout und Monitoring. Bei iOS-Apps beginnt der Prozess mit dem Hochladen des Builds in App Store Connect 24–48 Stunden vor dem geplanten Veröffentlichungsdatum aufgrund der obligatorischen Apple-Überprüfung. Bei Android wird der Build in der Google Play Console zusammengestellt und hochgeladen, wo der Überprüfungsprozess in der Regel 1–4 Stunden dauert. Laut Apple Developer Guidelines (2025) bestehen 90 % der Builds die Überprüfung innerhalb von 24 Stunden. Gestaffelter Rollout minimiert die Auswirkungen, wenn nach der Veröffentlichung Fehler entdeckt werden.
Wichtige Punkte
- Release-Tag — eine Reihe von Aktivitäten von der Build-Vorbereitung bis zum Monitoring nach dem Rollout
- Gestaffelter Rollout — schrittweise Ausrollung: 1 %, 10 %, 50 %, 100 %
- Smoke-Testing — letzte Überprüfung des Builds vor dem Einreichen in den Store
- Rollback-Plan — ein vorbereitetes Rollback-Szenario für kritische Fehler
- Release-Retrospektive — Analyse des Prozesses nach Abschluss des Rollouts auf 100 %
Was ist ein Release-Tag und wie bereitet man sich vor
Der Release-Tag ist nicht nur der Moment, in dem man den Veröffentlichungsbutton drückt. Es ist ein koordinierter Prozess, an dem Entwickler, QA, DevOps, Produktmanager und manchmal der Support beteiligt sind. Die Vorbereitung beginnt 2–3 Wochen vor dem Release-Tag: Festlegung des Umfangs, Code-Freeze, Regressionstests, Erstellung von Release-Notes und Marketingmaterialien. Je gründlicher die Vorbereitung, desto reibungsloser verläuft der Release-Tag.
Die Checkliste für die Vorbereitung des Release-Tags umfasst: finalen QA-Durchlauf (Regression + Smoke-Suite) auf dem Release-Build; Überprüfung der Metadaten in den Stores (Name, Beschreibung, Screenshots, Keywords); Abstimmung des Prozentsatzes des gestaffelten Rollouts mit dem Produktmanager; Erstellung eines Rollback-Plans (welcher Tag redeployed werden soll, wie lange es dauert); Benachrichtigung des Teams und der zugehörigen Dienste über das bevorstehende Release. Release-Checkliste sollte über CI/CD automatisiert werden — zum Beispiel als GitHub Actions-Workflow, der alle Punkte vor der Erstellung des Release-Tags überprüft.
Ein wichtiges Element der Vorbereitung ist die Blackout-Periode (Zeitraum, in dem Deployments in der Produktion verboten sind). In der Regel wird der Blackout 48 Stunden vor dem Release-Tag eingeführt und 24 Stunden nach erfolgreichem 100%igem Rollout aufgehoben. Change-Freeze während der Blackout-Periode gilt für alle Dienste, die mit dem Release zusammenhängen.
Build-Vorbereitung: Code-Freeze, Tagging und Zusammenstellung
24–48 Stunden vor dem Release-Tag wird ein Code-Freeze eingeführt — ein vollständiger Stopp von Codeänderungen. Die Entwickler konzentrieren sich auf die Erstellung von Dokumentation und Release-Notes. DevOps stellt den Release-Build aus einem festgelegten Tag (z. B. v2.6.0-rc1) zusammen. Der Build durchläuft eine vollständige Regression-Suite (automatische + manuelle Tests). Wenn kritische Fehler gefunden werden, werden sie vor dem Code-Freeze behoben oder das Release wird verschoben. Release-Kandidat (RC) — ein Build, der QA bestanden hat und zum Einreichen in den Store bereit ist.
Tagging in Git: Ein annotierter Tag wird erstellt (git tag -a v2.6.0 -m „Release v2.6.0“). Die CI/CD-Pipeline erstellt ein AAB (Android App Bundle) für Google Play und ein IPA (iOS App Store Package) für den Apple App Store. Dem Build beigefügt sind: eine Prüfsummendatei (SHA256), ein Changelog und eine Liste bekannter Probleme (Known Issues). Reproducible Builds — eine ideale Praxis, bei der die Neuerstellung aus demselben Tag ein binär identisches Ergebnis liefert.
bash
# Release-Pipeline — Tag-Erstellung und Build
# Geht davon aus, dass Code-Freeze bereits aktiv ist
# Release-Branch von develop erstellen
git checkout develop
git pull origin develop
git checkout -b release/v2.6.0
git push origin release/v2.6.0
# Code-Freeze: Branch-Schutzregeln blockieren neue PRs
# Regression-Suite in CI/CD ausführen
./gradlew clean testReleaseUnitTest connectedReleaseTest
# Release-Tag nach erfolgreichem QA erstellen
git tag -a v2.6.0 -m "Release v2.6.0: payment module, dark mode"
git push origin v2.6.0
# Release-Binärdatei über CI/CD erstellen
# fastlane build_release erzeugt AAB + universal APK
fastlane build_releaseWichtig: Der Version Bump (Aktualisierung von Version Code und Version Name) wird vor dem Code-Freeze durchgeführt. Nach dem Code-Freeze ändert sich die Version nicht. Für Android: versionCode — eine monoton steigende ganze Zahl; versionName — semantische Version (2.6.0). Für iOS: CFBundleVersion (Build-Nummer) und CFBundleShortVersionString (semantische Version). Versioning sollte in gradle/xcconfig automatisiert werden.
Hochladen in den Store und Überprüfungsprozess
Für iOS: Der Build wird über Xcode, Transporter oder fastlane in App Store Connect hochgeladen. Nach dem Hochladen durchläuft der Build eine automatische Apple-Überprüfung (Processing) und wird dann zur manuellen Überprüfung eingereicht. Die durchschnittliche Überprüfungszeit beträgt 24 Stunden, kann aber je nach Arbeitsbelastung der Apple-Reviewer und Compliance-Anforderungen zwischen 1 Stunde und 7 Tagen variieren. Expedited Review — eine Anfrage für eine beschleunigte Überprüfung bei kritischen Fehlerbehebungen (maximal einmal im Monat verfügbar, nicht garantiert).
Für Android: Der Build wird über die Google Play Console hochgeladen. Google verwendet einen kombinierten Ansatz: automatisierte Tests (Barrierefreiheit, Malware, Richtlinienkonformität) + selektive manuelle Überprüfung. Die durchschnittliche Überprüfungszeit beträgt 1–4 Stunden. Interner Test-Track und Closed Track ermöglichen finale Tests vor der Veröffentlichung im Production Track. Empfehlung: 1–2 Tage im Internen Test → 1 Tag in der Closed Beta → schrittweiser Production-Rollout.
Für beide Plattformen ist es entscheidend, die Metadaten vor dem Hochladen des Builds zu überprüfen: App-Name, Beschreibung (kurz + vollständig), Screenshots für jedes unterstützte Gerät (iPhone 6,5″, 5,5″, iPad, Android-Telefon, Tablet), Keywords (iOS) oder Store-Listing-Experimente (Android). Ein Fehler in den Metadaten kann die Überprüfung um einen weiteren Tag verzögern. App-Metadaten sollten für alle unterstützten Sprachen lokalisiert sein.
Gestaffelter Rollout: Wie man ein Release risikolos ausrollt
Gestaffelter Rollout (schrittweise Ausrollung, stufenweise Bereitstellung) ist eine Strategie, bei der eine neue Version den Benutzern nicht sofort, sondern schrittweise zur Verfügung gestellt wird. Ein typisches Schema für ein reifes Team: 1 % der Benutzer (erste 2–4 Stunden) → 10 % (24 Stunden) → 25 % (24 Stunden) → 50 % (24 Stunden) → 100 %. Jede Stufe umfasst die Überwachung von Metriken und die Prüfung auf kritische Fehler. Gestaffelter Rollout ist das wichtigste Instrument zur Risikominimierung bei Releases.
Die Google Play Console bietet einen integrierten gestaffelten Rollout: Sie können einen Benutzerprozentsatz festlegen und schrittweise Erhöhungen planen. Für iOS App Store Connect gibt es diese integrierte Funktion nicht — der gestaffelte Rollout wird über Phased Release (automatische Erhöhung der Abdeckung über 7 Tage mit Pausenmöglichkeit) oder über serverseitige Feature-Flags mit geografischer Verteilung implementiert. Phased Release in App Store Connect ermöglicht es, das Release bei Problemen zu pausieren.
Wichtige Metriken für den Übergang zur nächsten Stufe: Crash-Free-Rate (≥ 99,9 % für das neue Release), ANR-Rate (Android, ≤ 0,1 %), Fehlerrate auf der Backend-API (≤ 0,5 % 5xx), Benutzerbewertungen (nicht niedriger als bei der vorherigen Version), Apdex-Score (≥ 0,94). Wenn eine Metrik den Schwellenwert überschreitet, wird der Rollout bis zur Ursachenermittlung pausiert. Go/no-go-Gate auf jeder Stufe liegt in der Verantwortung des Release-Managers oder des Bereitschaftsingenieurs.
Monitoring nach dem Release: Worauf man in den ersten Stunden achten sollte
Die ersten 4 Stunden nach dem Release sind die kritischste Zeit. Das Team überwacht die Crash-Rate (Sentry, Firebase Crashlytics, App Center), die 5xx-Fehlerrate auf dem Backend, benutzerdefinierte Ereignisse (erfolgreiche Zahlungen, Anmeldungen, Registrierungen), Benutzerbewertungen im App Store und Google Play sowie Erwähnungen in sozialen Medien (Twitter, Reddit). Das Monitoring-Dashboard sollte im Voraus vorbereitet und auf einem großen Bildschirm im Büro oder in einem dedizierten Slack-Kanal verfügbar sein. Release-Dashboard — eine zentrale Ansicht für alle Release-Metriken.
Besondere Aufmerksamkeit gilt den Regressionsmetriken: Vergleich der Crash-Rate mit der vorherigen Version über einen ähnlichen Zeitraum. Wenn die Crash-Rate um mehr als 0,1 % gestiegen ist, ist dies eine rote Flagge, die eine sofortige Analyse erfordert. Wichtig ist auch der Vergleich der mittleren und p95-Latenz wichtiger API-Endpunkte: Selbst ohne Abstürze kann eine Erhöhung der Antwortzeit um 200 ms auf ein Problem hinweisen. Metrikvergleich (Basislinie vs. aktuell) wird in Datadog oder Grafana automatisiert.
Benutzerfeedback ist genauso wichtig wie numerische Metriken. In den ersten Stunden nach einem Release hinterlassen Benutzer aktiv Bewertungen in den Stores und schreiben an den Support. Fehler, die von Tests nicht erfasst wurden, tauchen schnell in den Bewertungen auf. Der Teamleiter oder ein beauftragter QA-Ingenieur überwacht die Bewertungen in den ersten 4 Stunden alle 30 Minuten und kategorisiert sie: falsch positiv, bekanntes Problem (bereits in der Liste der bekannten Probleme), neuer Fehler. Neue Fehler P0/P1 — ein Auslöser zum Anhalten des Rollouts.
Rollback: Wann und wie man ein Release zurücknimmt
Rollback ist die Rückkehr zu einer vorherigen stabilen Version, wenn kritische Probleme entdeckt werden. Die Entscheidung zum Rollback wird vom Release-Manager gemeinsam mit dem Tech Lead getroffen, wenn: die Crash-Free-Rate des neuen Releases unter 99 % fällt, ein Datenleck entdeckt wird, kritische Funktionen (Zahlungen, Authentifizierung) bei mehr als 5 % der Benutzer nicht funktionieren oder der Store (App Store Review) den Build nach der Veröffentlichung abgelehnt hat. Rollback-Trigger sollte vor dem Release definiert werden, damit die Entscheidung auf Fakten und nicht auf Emotionen basiert.
Für Android: Rollback in der Google Play Console bedeutet, den gestaffelten Rollout zu stoppen und zur vorherigen Version zu wechseln. Wenn der aktuelle Build bereits bei 100 % der Benutzer ist, veröffentlichen Sie die vorherige Version als neues Release. Für iOS: Über App Store Connect — Phased Release → Pause Release → Veröffentlichung einer neuen Version mit Fehlerbehebung (der App Store erlaubt keine Rückkehr zu einer vorherigen Version). iOS-Rollback ist komplexer: Der Entwickler muss einen neuen Build mit Revert-Commits erstellen und erneut die Überprüfung durchlaufen.
Nach einem Rollback wechselt das Team in den Incident-Modus: Ursachenanalyse, Hotfix oder nächstes Release mit Fehlerbehebung, Post-Mortem. Rollback ist kein Fehler, sondern ein Standardverfahren. Teams, die noch nie einen Rollback durchgeführt haben, bemerken Probleme wahrscheinlich nicht, anstatt fehlerfreie Releases zu veröffentlichen. Rollback-Rate ist eine der DORA-Metriken: Hochleistungsteams führen bei weniger als 10 % der Releases einen Rollback durch und erholen sich in weniger als 1 Stunde.
Häufig gestellte Fragen
An welchem Tag sollte man am besten eine mobile App veröffentlichen?
Die besten Tage sind Dienstag, Mittwoch oder Donnerstag. Montag hat hohen Verkehr vom Wochenende, und Freitag birgt das Risiko, mit einem problematischen Release ins Wochenende zu gehen. Vermeiden Sie Freitag: Wenn nach dem Deployment ein Problem entdeckt wird, wird das Team es am Wochenende beheben oder bis Montag warten müssen.
Was tun, wenn die App Store Review den Build ablehnt?
Lesen Sie den Ablehnungsgrund im Resolution Center, beheben Sie ihn und laden Sie den Build erneut hoch. Häufige Ursachen: defekte Links, unvollständige Felder, Inhalte ohne Abonnement (falls erforderlich), veraltete Screenshots. App Review-Ablehnung verzögert das Release um 24–48 Stunden, daher sollte der erste Build-Upload 3–5 Tage vor dem geplanten Veröffentlichungsdatum erfolgen.
Welcher Prozentsatz des gestaffelten Rollouts ist optimal für den Start?
Für große Releases (wesentliche Änderungen) — 1 %. Für Patch-Releases — 5–10 %. Die erste Stufe sollte klein genug sein, damit die Auswirkungen im Fehlerfall minimal sind, aber groß genug, um statistisch signifikante Metriken zu erhalten. 1 % bei einer App mit 10 Millionen Benutzern sind 100.000 Personen — ausreichend, um kritische Probleme zu erkennen.
Sollte man eine Release-Party machen?
Eine Release-Party (Team-Feier) ist optional, aber gut für die Moral. Besser nach einem erfolgreichen 100%igen Rollout durchführen, nicht im Moment des Build-Uploads. Release-Feier kann mit einer Release-Retrospektive kombiniert werden, um zu besprechen, was gut gelaufen ist und was verbessert werden kann.
Wer ist für die Entscheidung „Release oder Verschieben“ verantwortlich?
Die Verantwortung liegt beim Release-Manager (in der Regel ein Senior Engineer oder Tech Lead). Die Entscheidung wird auf der Grundlage der Daten des Release-Dashboards getroffen, nicht auf der Grundlage der Frist. Release-Manager hat die Befugnis, das Release zu verzögern, wenn die Metriken das Go/no-go-Gate nicht bestehen.
Zusammenfassung
- Release-Tag — koordinierter Prozess vom Code-Freeze bis zum Monitoring nach dem Rollout
- Vorbereitung — Release-Kandidat, QA-Durchlauf, Metadatenprüfung, Rollback-Plan
- Gestaffelter Rollout — 1 % → 10 % → 25 % → 50 % → 100 % mit Go/no-go-Gate auf jeder Stufe
- Monitoring — Crash-Free-Rate, ANR, 5xx-Fehlerrate, Benutzerbewertungen in den ersten 4 Stunden
- Rollback — Standardverfahren, wenn die Crash-Free-Rate unter 99 % fällt
- Kommunikation — Benachrichtigung des Teams und der Stakeholder vor und nach dem Release
- Release-Retrospektive — Prozessüberprüfung nach Abschluss des Rollouts auf 100 %
Wir entwickeln eine mobile Applikation schlüsselfertig
IT Sectr entwickelt seit 2017 iOS- und Android-Apps für Startups und Unternehmen. Wir beraten Sie und schlagen die beste Lösung vor.
Lesen Sie auch