LaunchLint Academy
La risposta breve
- Una release di produzione su Google Play non consiste solo nel caricamento di un Android App Bundle. Scheda, App content, Data safety, test, firma e rollout devono descrivere lo stesso build e risolvere ogni avviso bloccante.
- Questa guida accompagna i team Expo e React Native da una release candidate congelata a un lancio controllato, includendo prove, responsabilità, soglie di arresto e monitoraggio.
- Subito prima della produzione esegui una prova con ruoli espliciti. Una persona usa Play Console, una installa solo l’artefatto del track previsto e una controlla monitoring e backend. Parti da un account nuovo, prova aggiornamento e installazione pulita, genera almeno un errore controllato e verifica supporto e privacy. Confronta l’app visibile con scheda, screenshot, Data safety e note. Registra orario, build, dispositivi, risultati ed eccezioni. Il candidato entra in produzione solo quando ogni differenza ha un responsabile e una decisione esplicita. Ripeti poi i controlli principali dopo il primo aumento del rollout, perché consegna reale, configurazioni remote e carico possono mostrare problemi assenti nel test chiuso. Mantieni pronta la possibilità di sospendere e comunica in anticipo chi prende quella decisione. Una checklist senza autorità operativa non protegge il lancio.
- Archivia solo risultati verificabili: stato della console, ID dell’artefatto, rapporto di test, matrice approvata e decisione di rollout. Non inserire chiavi, segreti di firma o dati personali. Controlla anche chi può modificare la produzione e rimuovi i permessi temporanei dopo l’uscita; una release tecnicamente corretta rimane fragile quando troppi account possono cambiarla senza approvazione. Verifica che notifiche operative e contatti siano attivi durante tutta la finestra e registra il momento esatto in cui ogni gate è stato superato.
Congelare candidato e versioni
Segna un commit come candidato ed evita cambi silenziosi a codice, configurazione o dipendenze native. Codice e nome versione, package e profilo Expo EAS devono identificare senza ambiguità l’AAB generato.
Registra checksum, link, commit, orario e responsabile. Tester, Play Console e team lavorano così sullo stesso artefatto riproducibile.
Registro
- Commit e versioni registrati
- Profilo e package verificati
- Checksum e posizione AAB conservati
- Nessuna modifica tardiva
- Responsabile nominato
Verificare bundle e firma
Google Play riceve Android App Bundle e crea APK ottimizzati. Controlla che il bundle sia quello previsto e che Play App Signing sia configurato correttamente. Un problema di chiave o package non è una piccola modifica di metadati.
Con Expo verifica profilo di produzione, credenziali e application identifier prima del build. Non cambiare una chiave in fretta per aggirare un errore di upload.
Bundle e firma
- Pubblicare AAB
- Controllare Play App Signing
- Confermare package
- Ispezionare artefatto
- Proteggere credenziali
Allineare la scheda Play
Titolo, descrizioni, icona, feature graphic, screenshot, contatti e privacy devono essere completi. Ogni promessa deve corrispondere al candidato; immagini di prototipo e funzioni rimosse aumentano rischio di revisione e sfiducia.
Controlla ogni lingua singolarmente. Una scheda predefinita completa può nascondere risorse localizzate vecchie. Usa una matrice con locale, risorsa, owner e data.
Scheda
- Testi fedeli
- Grafiche aggiornate
- Link funzionanti
- Lingue controllate
- Contatto presidiato
Completare App content e Data safety
App content comprende privacy, pubblicità, accesso, pubblico, permessi, classificazione, Data safety e altre dichiarazioni. Sono affermazioni pubbliche rilevanti per la revisione, non semplice burocrazia.
Deriva le risposte da codice, inventario SDK e flussi backend. Se un SDK tratta dati, il modulo deve rifletterlo. Il questionario non sostituisce le prove tecniche.
App content
- Pubblicità e pubblico corretti
- Accesso reviewer pronto
- Permessi spiegati
- Data safety verificato
- Classificazione completa
Usare test interni e chiusi
Un track interno consente controlli rapidi; un test chiuso amplia dispositivi e uso reale. Installa la versione distribuita da Play per verificare firma, split, aggiornamenti e contesto store, non solo un debug locale.
Definisci criteri per primo avvio, login, flusso principale, acquisti, permessi, deep link, offline ed errori. Ogni bug deve indicare build e dispositivo.
Copertura
- Installare da Play
- Testare installazione e update
- Coprire flussi ed errori
- Verificare acquisti e deep link
- Allegare build e dispositivo
Valutare il rapporto preliminare
Il pre-launch report esegue il bundle su dispositivi e può evidenziare stabilità, prestazioni, accessibilità e sicurezza. È un segnale aggiuntivo, non sostituisce i test specifici.
Classifica ogni risultato come blocco riproducibile, rischio, limite noto o falso positivo e documenta la decisione. Avvisi ignorati senza motivo ricompaiono e perdono valore.
Triage
- Riprodurre crash e ANR
- Valutare prestazioni e accessibilità
- Assegnare sicurezza
- Spiegare falsi positivi
- Chiudere i blocchi
Controllare il rollout
Crea la release quando scheda e App content sono completi e non restano errori bloccanti. Le note devono descrivere il cambiamento reale.
Un rollout graduale limita l’impatto dei difetti sconosciuti. Definisci percentuale iniziale, finestra, owner e soglie di stop prima di avanzare; senza gate è solo una release totale più lenta.
Gate di rollout
- Nessun errore bloccante
- Note esatte
- Percentuale e finestra definite
- Soglie di stop fissate
- Owner può sospendere
Monitorare e documentare
Dopo la pubblicazione osserva crash, ANR, recensioni, supporto, errori backend e funnel critici. Confronta con una base nota per distinguere la variabilità normale da una regressione.
Chiudi registrando versione, orari, fasi, anomalie e attività successive. Lo storico accelera le release future e mostra problemi ricorrenti.
Operazioni
- Confrontare con baseline
- Osservare supporto e recensioni
- Controllare backend e funnel
- Avanzare dopo il gate
- Salvare le lezioni
Domande frequenti
Serve un AAB?
L’Android App Bundle è l’artefatto standard e Google Play genera APK ottimizzati.
Basta caricarlo correttamente?
No. Vanno completati scheda, App content, informativa sulla privacy, test ed errori bloccanti.
Conviene partire al 100 %?
Per cambi importanti un rollout graduale con soglie definite limita il rischio.
Il pre-launch report sostituisce la QA?
No. Aggiunge segnali da dispositivi ma non copre tutti i flussi del prodotto.
Quale build devono installare i tester?
Preferibilmente quello distribuito da un track Play per verificare firma, consegna e aggiornamenti reali.