Pruebas internas, lanzamiento gradual y producción
Publique primero en un canal de pruebas internas, pase después a las pruebas cerradas y abiertas y, por último, realice un lanzamiento gradual en producción mediante un porcentaje de despliegue escalonado y supervise las tasas de fallos.
Pruebas internas, lanzamiento gradual y producción es una lección gratuita de React Native Academy en CoddyKit. Esta es la lección 4 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de React Native Academy, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de React Native Academy incluye 4 lecciones en total.
Partes de esta lección aún no han sido traducidas y se muestran en inglés.
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.
Preguntas frecuentes
¿La lección «Pruebas internas, lanzamiento gradual y producción» es gratis?
Sí — el texto completo de «Pruebas internas, lanzamiento gradual y producción» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de React Native Academy, actualiza a CoddyKit PRO. El curso de React Native Academy incluye 4 lecciones en total.
¿Qué aprenderé en «Pruebas internas, lanzamiento gradual y producción»?
Publique primero en un canal de pruebas internas, pase después a las pruebas cerradas y abiertas y, por último, realice un lanzamiento gradual en producción mediante un porcentaje de despliegue escal… Practicas React Native Academy con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.
¿Necesito experiencia previa para empezar React Native Academy?
No se requiere experiencia previa. React Native Academy en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 4 de 4.
¿Cuánto tiempo toma la lección «Pruebas internas, lanzamiento gradual y producción»?
La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.
¿Puedo escribir y ejecutar código en esta lección de React Native Academy?
Sí. Cada lección de React Native Academy incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.
Todas las lecciones de este curso
- Creación de un Keystore y firma del AAB
- Configuración de la ficha en Play Console
- Clasificaciones de contenido, políticas y privacidad
- Pruebas internas, lanzamiento gradual y producción