Test interno, rilascio graduale e produzione
Pubblichi inizialmente su un canale di test interno, passi ai test chiusi e aperti, quindi distribuisca gradualmente in produzione utilizzando una percentuale di rilascio graduale e monitori il tasso di arresti anomali.
Test interno, rilascio graduale e produzione è una lezione React Native Academy gratuita su CoddyKit. Questa è la lezione 4 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento React Native Academy, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso React Native Academy include 4 lezioni in totale.
Parti di questa lezione non sono ancora state tradotte e vengono mostrate in inglese.
The Four Release Tracks
Google Play Console offers four release tracks forming a progressive rollout pipeline. Internal testing reaches up to 100 testers instantly with no review. Closed testing (alpha) targets a specific invite list. Open testing (beta) allows anyone to opt in publicly. Production reaches all users in your selected countries. Each track acts as a safety gate — you validate quality at each level before promoting to the next.
// Release track comparison:
// Internal Testing:
// Testers: up to 100 (by email/Google Group)
// Availability: Instant (no Google review)
// Visibility: Hidden from public
// Best for: Team + QA testing
// Closed Testing (Alpha):
// Testers: Specific invite list (no limit)
// Availability: After brief automated check
// Visibility: Hidden from public
// Best for: Beta test with partners/selected users
// Open Testing (Beta):
// Testers: Anyone who opts in
// Availability: Visible public beta badge
// Best for: Community feedback before launchSetting Up Internal Testing
Internal testing is your first stop after a successful build. Create an internal testing release, upload the AAB, and add testers by email or a Google Group. Testers receive an email with an opt-in link — they must click it and then find the app in Play Store to install it. Internal testing builds are delivered within minutes of publishing (unlike production which can take hours for processing). Always verify core flows pass here before promoting.
// Internal testing setup:
// Testing > Internal testing > Testers tab
// > Create email list: 'Core Team'
// > Add emails:
// alice@yourcompany.com
// bob@yourcompany.com
// qa@yourcompany.com
// Share the opt-in link with testers:
// 'Join the test at this link: [opt-in URL]'
// Testers click link, then search for the app on Play Store
// App appears with an 'Internal' badge
// Tester checklist:
// [ ] Sign up flow works
// [ ] Core feature performs correctly
// [ ] No crashes in main pathsCreating a Closed Testing Track
Closed testing (alpha) is useful for a wider, invite-only group before public launch — beta users, influencers, or partners. Create the release the same way as internal testing: upload the same or a newer AAB, write release notes, and publish. Add testers via email lists in the Testers tab. You can have multiple closed testing tracks with different configurations (e.g., one track for feature testing, another for localization testing).
// Create a closed testing release:
// Testing > Closed testing > Create new track
// Track name: 'Alpha'
// Add testers:
// Testers > Create email list: 'Alpha Testers'
// Or: Add a Google Group email
// (all group members become testers automatically)
// Promote an internal build to closed testing:
// Testing > Internal testing > Releases
// Select the release > Promote release
// > Closed testing > ConfirmOpen Testing (Public Beta)
Open testing makes your app available to any Play Store user who opts in to the beta program. A 'Join the beta' button appears on your app's Play Store listing page. Beta users see the label 'Beta' on the app and their reviews are separate from production reviews. Use open testing to get broader real-world feedback and crash data from device configurations you don't own before the public production launch.
// Open testing setup:
// Testing > Open testing > Create new release
// Set the percentage of users who can join (optional)
// The opt-in URL for beta is shareable:
// 'Try our beta at: play.google.com/store/apps/...
// (scroll down and click Join the beta)'
// Benefits of open testing:
// - Real crash data from diverse devices
// - Public rating separate from production
// - Community can submit feedback
// - Validates localization on regional devices
// Tip: Announce the beta on social media
// to quickly gather a large tester poolPromoting to Production
Promoting from open testing (or internal) to production is the key step. Go to Testing > Open testing, find your release, and click Promote release > Production. The first promotion to production triggers Google's review (usually 1–3 business days). Subsequent updates are reviewed faster. After review, the app appears in Play Store search results and your target countries' store listings.
// Promote to production:
// Testing > Open testing (or Internal)
// > Select release > Promote release
// > Production > Next
// Set initial rollout percentage:
// 10%, 20%, 50%, or 100%
// (for first launch, 100% is fine — you have no existing users)
// For updates to existing apps:
// Use staged rollout starting at 10–20%
// to catch issues before full deployment
// Review timeline:
// First submission: 3-7 business days
// Updates: Usually 1-3 business days
// (faster if no new permissions or policy changes)Staged Rollout to Production
Staged rollout releases an update to a percentage of your existing users rather than everyone at once. Start at 5–20% and monitor crash rates, ANR rates, and negative reviews. If metrics look good after 24–48 hours, increase the percentage. If you detect a critical bug, halt the rollout immediately — users who already received the update keep it, but no new users get it while you fix and resubmit.
// Staged rollout steps:
// Production > Create new release
// Upload new .aab (versionCode must be higher)
// Write release notes: 'Fixed startup crash on Android 13.'
// > Review release
// > Start rollout to production
// Set rollout percentage: 10%
// Monitor for 24-48 hours:
// Android vitals > Crash rate and ANR rate
// If stable: increase to 20%, 50%, 100%
// Production > Manage rollout > Update rollout percentage
// If broken: halt rollout
// Production > Manage rollout > Halt rolloutMonitoring Crashes with Android Vitals
Android Vitals in Play Console shows real-time crash rates and ANR (Application Not Responding) rates from production users. Google benchmarks these against similar apps in your category. If your crash rate is above the bad behavior threshold (typically ~1.09%), Play Console may add a warning badge to your store listing and reduce your search ranking. Investigate the provided stack traces in the Crashes section to prioritize fixes.
// Android Vitals > Crashes and ANRs
// Shows:
// Crash rate: 0.47% (Good)
// ANR rate: 0.12% (Good)
// Core vitals: All passing
// Crash cluster view:
// Each distinct crash signature grouped
// Tap a cluster to see:
// - Full stack trace
// - Affected devices
// - Android versions affected
// - Number of affected users
// - First/last occurrence
// Export traces to integrate with Sentry or Crashlytics
// for richer crash context (user actions before crash)Managing Ratings and Reviews
Responding to user reviews shows you care about quality and often converts a negative review to a positive one after fixing the reported issue. In Play Console, go to Grow > Ratings and reviews to see and reply to reviews. Filtered views let you see reviews by version (useful for regression detection), star rating, and country. Negative reviews from a specific version pinpoint when a regression was introduced.
// Review response best practices:
// 1-star review: 'App crashes on startup'
// Your reply:
// 'Hi, we are sorry to hear about the crash!
// This was fixed in version 1.2.3 released yesterday.
// Please update and let us know if the issue persists.
// You can also reach us at support@yourapp.com.'
// 4-star: 'Great app but missing dark mode'
// Your reply:
// 'Thank you for the feedback! Dark mode is on our
// roadmap for the next update (v1.3). Stay tuned!'
// Tip: Prioritize recent 1- and 2-star reviewsVersion Code Increment Strategy
Play Console rejects an upload if the versionCode is not higher than the last uploaded build. A simple strategy is to increment by 1 for each upload. If you maintain multiple release channels (internal, beta, production) simultaneously, reserve ranges: e.g., 1000–1099 for internal testing, 2000–2099 for production. EAS Build can auto-increment versionCode with the autoIncrement: true flag in eas.json.
// Auto-increment with EAS:
// eas.json
{
'build': {
'production': {
'android': {
'buildType': 'app-bundle',
'autoIncrement': true // EAS increments versionCode
}
}
}
}
// Manual strategy in app.json:
// Before each production build:
// Increment android.versionCode by 1
// Update version string if user-facing change
// Current: { 'version': '1.2.3', 'versionCode': 15 }
// Next: { 'version': '1.2.4', 'versionCode': 16 }Using Firebase Crashlytics for Deeper Crash Analysis
While Android Vitals shows aggregated crash data, Firebase Crashlytics gives richer context: the sequence of user actions before the crash, custom log messages you added, user device info, and non-fatal error tracking. Integrate Crashlytics with @react-native-firebase/crashlytics. Log custom keys before critical operations so when a crash report comes in, you know exactly what the user was doing at that moment.
import crashlytics from '@react-native-firebase/crashlytics';
// Log custom keys for crash context
async function loadUserProfile(userId) {
crashlytics().setUserId(userId);
crashlytics().setAttribute('screen', 'ProfileScreen');
crashlytics().log('Fetching user profile...');
try {
const profile = await api.getUserProfile(userId);
crashlytics().log('Profile loaded successfully');
return profile;
} catch (error) {
// Log non-fatal error and rethrow
crashlytics().recordError(error);
throw error;
}
}Rollout Completion and Store Presence
Once you reach 100% rollout, your app is fully live and indexed by Google Play's search algorithm. It may take 24–48 hours for the app to fully propagate and be discoverable in all regions via search. Monitor your Acquire metrics: store listing visitors, install conversion rate, and organic vs paid install sources. A launch week spike in installs followed by retention data tells you how well your app delivers on its store listing promise.
// Post-launch monitoring checklist:
// Day 1-3:
// [ ] Crash rate < 1.09% (Play benchmark)
// [ ] ANR rate < 0.47%
// [ ] Check ratings for immediate feedback
// [ ] Verify deep links work from the live listing
// Week 1:
// [ ] Install count vs impressions (conversion rate)
// [ ] D1 retention (users returning next day)
// [ ] Revenue if paid/IAP
// Ongoing:
// [ ] Respond to all 1- and 2-star reviews within 24h
// [ ] Monitor Android vitals weekly
// [ ] Release updates with new features and fixesQuick Check
Test your understanding of React Native Mobile Development concepts from this lesson.
Lesson Recap
In this lesson you learned: how the four Play Console release tracks (internal, closed, open, production) form a quality gate pipeline, how staged rollout lets you limit blast radius when releasing updates, and how to monitor crash rates with Android Vitals and Crashlytics. You also saw how to respond to reviews and auto-increment versionCode with EAS. Next up is the capstone: planning and building a full React Native app.
Domande Frequenti
La lezione «Test interno, rilascio graduale e produzione» è gratuita?
Sì — il testo completo di «Test interno, rilascio graduale e produzione» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso React Native Academy, passa a CoddyKit PRO. Il corso React Native Academy include 4 lezioni in totale.
Cosa imparerò in «Test interno, rilascio graduale e produzione»?
Pubblichi inizialmente su un canale di test interno, passi ai test chiusi e aperti, quindi distribuisca gradualmente in produzione utilizzando una percentuale di rilascio graduale e monitori il tasso… Eserciti React Native Academy con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.
Ho bisogno di esperienza per iniziare React Native Academy?
Non è richiesta alcuna esperienza precedente. React Native Academy su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 4 di 4.
Quanto tempo richiede la lezione «Test interno, rilascio graduale e produzione»?
La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.
Posso scrivere ed eseguire codice in questa lezione React Native Academy?
Sì. Ogni lezione React Native Academy include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.
Tutte le lezioni di questo corso
- Creare un keystore e firmare l'AAB
- Configurare la scheda su Play Console
- Classificazione dei contenuti, norme e privacy
- Test interno, rilascio graduale e produzione