Giorno del rilascio nello sviluppo di app: essenza, fasi e preparazione
Il giorno del rilascio (release day) è la data programmata per il rilascio di una nuova versione di un’app mobile, che include la preparazione del build, la revisione dello store, il rollout graduale (staged rollout) e il monitoraggio. Per le app iOS, il processo inizia con il caricamento del build su App Store Connect 24-48 ore prima della data di rilascio pianificata a causa della revisione obbligatoria di Apple. Per Android, il build viene assemblato e caricato su Google Play Console, dove il processo di revisione richiede solitamente 1-4 ore. Secondo le Apple Developer Guidelines (2025), il 90% dei build supera la revisione entro 24 ore. Il rollout graduale consente di minimizzare l’impatto in caso di errori scoperti dopo la pubblicazione.
Punti chiave
- Giorno del rilascio — insieme di attività dalla preparazione del build al monitoraggio post-rollout
- Rollout graduale — distribuzione progressiva: 1%, 10%, 50%, 100%
- Smoke testing — verifica finale del build prima dell’invio allo store
- Piano di rollback — scenario di rollback preparato in anticipo per errori critici
- Retrospettiva del rilascio — analisi del processo dopo il completamento del rollout al 100%
Cos’è il giorno del rilascio e come prepararsi
Il giorno del rilascio non è solo il momento di premere il pulsante Pubblica. È un processo coordinato che coinvolge sviluppatori, QA, DevOps, product manager e talvolta il supporto. La preparazione inizia 2-3 settimane prima del giorno del rilascio: definizione dell’ambito, code freeze, test di regressione, preparazione delle note di rilascio e dei materiali di marketing. Più la preparazione è accurata, più il giorno del rilascio si svolge senza intoppi.
La checklist di preparazione per il giorno del rilascio include: esecuzione finale di QA (suite di regressione + smoke) sul build di rilascio; verifica dei metadati negli store (nome, descrizione, screenshot, parole chiave); accordo sulla percentuale di rollout graduale con il product manager; preparazione del piano di rollback (quale tag ridistribuire, quanto tempo richiederà); notifica al team e ai servizi correlati del prossimo rilascio. La checklist di rilascio dovrebbe essere automatizzata tramite CI/CD — ad esempio, come un workflow di GitHub Actions che verifica tutti i punti prima di creare il tag di rilascio.
Un elemento importante della preparazione è il blackout period (periodo in cui i deploy in produzione sono vietati). Di solito, il blackout viene introdotto 48 ore prima del giorno del rilascio e rimosso 24 ore dopo un rollout riuscito al 100%. Il blocco delle modifiche durante il periodo di blackout si applica a tutti i servizi correlati al rilascio.
Preparazione del build: code freeze, tagging e assemblaggio
24-48 ore prima del giorno del rilascio, viene introdotto un code freeze — un arresto completo delle modifiche al codice. Gli sviluppatori si dedicano alla preparazione della documentazione e delle note di rilascio. Il DevOps assembla il build di rilascio da un tag fisso (es. v2.6.0-rc1). Il build passa attraverso una suite completa di regressione (test automatici + manuali). Se vengono trovati bug critici, vengono corretti prima del code freeze o il rilascio viene rinviato. Il candidato al rilascio (RC) — un build che ha superato il QA ed è pronto per l’invio allo store.
Tagging in Git: viene creato un tag annotato (git tag -a v2.6.0 -m “Release v2.6.0”). La pipeline CI/CD compila un AAB (Android App Bundle) per Google Play e un IPA (iOS App Store Package) per l’Apple App Store. Il build è accompagnato da: un file di checksum (SHA256), un changelog e un elenco di problemi noti (known issues). Build riproducibili — una pratica ideale in cui la ricompilazione dallo stesso tag produce un risultato binaramente identico.
bash
# Pipeline di release — creazione del tag e build
# Presuppone che il code freeze sia già attivo
# Creare il branch di release da develop
git checkout develop
git pull origin develop
git checkout -b release/v2.6.0
git push origin release/v2.6.0
# Code freeze: le regole di protezione del branch bloccano nuove PR
# Eseguire la suite di regressione in CI/CD
./gradlew clean testReleaseUnitTest connectedReleaseTest
# Creare il tag di release dopo QA superato
git tag -a v2.6.0 -m "Release v2.6.0: payment module, dark mode"
git push origin v2.6.0
# Compilare il binario di release tramite CI/CD
# fastlane build_release produce AAB + universal APK
fastlane build_releaseImportante: il version bump (aggiornamento di version code e version name) viene effettuato prima del code freeze. Dopo il code freeze, la versione non cambia. Per Android: versionCode — un intero monotonicamente crescente; versionName — versione semantica (2.6.0). Per iOS: CFBundleVersion (build number) e CFBundleShortVersionString (versione semantica). Il versioning dovrebbe essere automatizzato in gradle/xcconfig.
Caricamento nello store e processo di revisione
Per iOS: il build viene caricato tramite Xcode, Transporter o fastlane su App Store Connect. Dopo il caricamento, il build viene sottoposto a un controllo automatico di Apple (processing), quindi inviato per la revisione manuale. Il tempo medio di revisione è di 24 ore, ma può variare da 1 ora a 7 giorni a seconda del carico di lavoro dei revisori Apple e dei requisiti di conformità. La revisione accelerata — una richiesta di revisione rapida per correzioni di bug critici (disponibile al massimo una volta al mese, non garantita).
Per Android: il build viene caricato tramite Google Play Console. Google utilizza un approccio combinato: test automatici (accessibilità, malware, conformità alle politiche) + revisione manuale selettiva. Il tempo medio di revisione è di 1-4 ore. Il track di test interno e il track chiuso consentono test finali prima della pubblicazione nel track di produzione. Raccomandazione: 1-2 giorni in test interno → 1 giorno in beta chiusa → rollout graduale in produzione.
Per entrambe le piattaforme, è fondamentale verificare i metadati prima di caricare il build: nome dell’app, descrizione (breve + completa), screenshot per ogni dispositivo supportato (iPhone 6,5″, 5,5″, iPad, telefono Android, tablet), parole chiave (iOS) o esperimenti di store listing (Android). Un errore nei metadati può ritardare la revisione di un giorno aggiuntivo. I metadati dell’app dovrebbero essere localizzati in tutte le lingue supportate.
Rollout graduale: come distribuire un rilascio senza rischi
Il rollout graduale (distribuzione progressiva, implementazione a fasi) è una strategia in cui una nuova versione diventa disponibile per gli utenti gradualmente, non tutta in una volta. Uno schema tipico per un team maturo: 1% degli utenti (prime 2-4 ore) → 10% (24 ore) → 25% (24 ore) → 50% (24 ore) → 100%. Ogni fase include il monitoraggio delle metriche e la verifica dell’assenza di errori critici. Il rollout graduale è lo strumento principale per minimizzare i rischi durante i rilasci.
Google Play Console offre un rollout graduale integrato: è possibile specificare una percentuale di utenti e programmare aumenti graduali. Per iOS App Store Connect, non esiste una funzionalità integrata di questo tipo — il rollout graduale viene implementato tramite Phased Release (aumento automatico della copertura in 7 giorni con possibilità di pausa) o tramite feature flag lato server con geo-distribuzione. Il Phased Release in App Store Connect consente di mettere in pausa il rilascio se vengono rilevati problemi.
Metriche chiave per passare alla fase successiva: crash-free rate (≥99,9% per il nuovo rilascio), tasso di ANR (Android, ≤0,1%), tasso di errore sull’API backend (≤0,5% 5xx), valutazioni degli utenti (non inferiori alla versione precedente), punteggio apdex (≥0,94). Se una qualsiasi metrica supera la soglia, il rollout viene messo in pausa fino alla determinazione della causa. Il gate go/no-go in ogni fase è responsabilità del release manager o dell’ingegnere di turno.
Monitoraggio post-rilascio: cosa osservare nelle prime ore
Le prime 4 ore dopo il rilascio sono il momento più critico. Il team monitora il tasso di crash (Sentry, Firebase Crashlytics, App Center), il tasso di errore 5xx sul backend, eventi personalizzati (pagamenti riusciti, login, registrazioni), le valutazioni degli utenti nell’App Store e Google Play e le menzioni sui social media (Twitter, Reddit). Il dashboard di monitoraggio dovrebbe essere preparato in anticipo e disponibile su un grande schermo in ufficio o in un canale Slack dedicato. Il dashboard di rilascio — un’unica finestra per tutte le metriche del rilascio.
Attenzione particolare alle metriche di regressione: confronto del tasso di crash con la versione precedente in un periodo simile. Se il tasso di crash è aumentato di oltre lo 0,1%, questa è una bandiera rossa che richiede un’analisi immediata. È importante anche confrontare la latenza mediana e p95 degli endpoint API chiave: anche senza crash, un aumento di 200ms nel tempo di risposta può segnalare un problema. Il confronto delle metriche (baseline vs corrente) è automatizzato in Datadog o Grafana.
Il feedback degli utenti è importante quanto le metriche numeriche. Nelle prime ore dopo un rilascio, gli utenti lasciano attivamente recensioni negli store e scrivono al supporto. I bug non catturati dai test emergono rapidamente nelle recensioni. Il team leader o un ingegnere QA designato monitora le recensioni ogni 30 minuti nelle prime 4 ore e le classifica: falso positivo, problema noto (già nell’elenco dei known issues), nuovo bug. Nuovi bug P0/P1 — un trigger per mettere in pausa il rollout.
Rollback: quando e come annullare un rilascio
Il rollback è il ritorno a una versione stabile precedente quando vengono scoperti problemi critici. La decisione di rollback viene presa dal release manager insieme al tech lead se: il crash-free rate del nuovo rilascio scende sotto il 99%, viene rilevata una perdita di dati, la funzionalità critica (pagamenti, autenticazione) non funziona per più del 5% degli utenti, o lo store (App Store Review) ha rifiutato il build dopo la pubblicazione. Il trigger di rollback deve essere definito prima del rilascio in modo che la decisione sia basata sui fatti, non sulle emozioni.
Per Android: il rollback in Google Play Console significa arrestare il rollout graduale e passare alla versione precedente. Se il build corrente è già al 100% degli utenti, pubblicare la versione precedente come nuovo rilascio. Per iOS: tramite App Store Connect — Phased Release → Pause Release → rilasciare una nuova versione con la correzione (l’App Store non consente di tornare a una versione precedente). Il rollback iOS è più complesso: lo sviluppatore deve compilare un nuovo build con revert commit e ripassare la revisione.
Dopo un rollback, il team entra in modalità incidente: analisi delle cause profonde, hotfix o prossimo rilascio con la correzione, post-mortem. Il rollback non è un fallimento ma una procedura standard. I team che non hanno mai effettuato un rollback probabilmente non notano i problemi, non è che pubblicano versioni senza bug. Il rollback rate è una delle metriche DORA: i team ad alte prestazioni rollback meno del 10% dei rilasci e si riprendono in meno di 1 ora.
Domande frequenti
Qual è il giorno migliore per rilasciare un’app mobile?
I giorni migliori sono martedì, mercoledì o giovedì. Il lunedì ha traffico elevato dal fine settimana e il venerdì comporta il rischio di entrare nel fine settimana con un rilascio problematico. Evita il venerdì: se viene scoperto un problema dopo il deploy, il team lo correggerà durante il fine settimana o aspetterà fino a lunedì.
Cosa fare se l’App Store Review rifiuta il build?
Leggi il motivo del rifiuto nel Resolution Center, correggi e ricarica il build. Cause comuni: link rotti, campi incompleti, contenuto senza abbonamento (se richiesto), screenshot obsoleti. Il rifiuto dell’App Review ritarda il rilascio di 24-48 ore, quindi il primo caricamento del build dovrebbe avvenire 3-5 giorni prima della data di rilascio pianificata.
Quale percentuale di rollout graduale è ottimale per iniziare?
Per rilasci importanti (modifiche sostanziali) — 1%. Per rilasci di patch — 5-10%. La prima fase dovrebbe essere abbastanza piccola da rendere minimo l’impatto in caso di errore, ma abbastanza grande da ottenere metriche statisticamente significative. 1% per un’app con 10 milioni di utenti sono 100.000 persone — sufficienti per rilevare problemi critici.
Bisogna fare una festa di rilascio?
Una festa di rilascio (celebrazione di squadra) è facoltativa ma benefica per il morale. È meglio svolgerla dopo un rollout riuscito al 100%, non al momento del caricamento del build. La celebrazione del rilascio può essere combinata con una retrospettiva del rilascio per discutere cosa è andato bene e cosa può essere migliorato.
Chi è responsabile della decisione “rilasciare o rinviare”?
La responsabilità spetta al release manager (di solito un ingegnere senior o un tech lead). La decisione viene presa in base ai dati del dashboard di rilascio, non in base alla scadenza. Il release manager ha l’autorità di ritardare il rilascio se le metriche non superano il gate go/no-go.
Riepilogo
- Giorno del rilascio — processo coordinato dal code freeze al monitoraggio post-rollout
- Preparazione — candidato al rilascio, esecuzione QA, verifica metadati, piano di rollback
- Rollout graduale — 1% → 10% → 25% → 50% → 100% con gate go/no-go in ogni fase
- Monitoraggio — crash-free rate, ANR, tasso di errore 5xx, valutazioni nelle prime 4 ore
- Rollback — procedura standard quando il crash-free rate scende sotto il 99%
- Comunicazione — notifica al team e agli stakeholder prima e dopo il rilascio
- Retrospettiva del rilascio — revisione del processo dopo il completamento del rollout al 100%
Svilupperemo un'applicazione mobile chiavi in mano
IT Sectr crea applicazioni iOS e Android per startup e aziende dal 2017. Ti consulteremo e ti proporremo la soluzione migliore.
Leggi anche