Tests internes, déploiement progressif et production
Publiez d'abord sur une piste de test interne, passez aux tests fermés puis ouverts, déployez progressivement en production selon un pourcentage défini, puis surveillez le taux de plantages.
Tests internes, déploiement progressif et production est une leçon React Native Academy gratuite sur CoddyKit. Ceci est la leçon 4 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage React Native Academy, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours React Native Academy comprend 4 leçons au total.
Certaines parties de cette leçon n'ont pas encore été traduites et s'affichent en anglais.
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.
Questions Fréquemment Posées
La leçon « Tests internes, déploiement progressif et production » est-elle gratuite ?
Oui — le texte complet de « Tests internes, déploiement progressif et production » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours React Native Academy, passe à CoddyKit PRO. Le cours React Native Academy comprend 4 leçons au total.
Qu'est-ce que j'apprendrai dans « Tests internes, déploiement progressif et production » ?
Publiez d'abord sur une piste de test interne, passez aux tests fermés puis ouverts, déployez progressivement en production selon un pourcentage défini, puis surveillez le taux de plantages. Tu pratiques React Native Academy avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.
Dois-je avoir de l'expérience pour commencer React Native Academy ?
Aucune expérience préalable n'est requise. React Native Academy sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 4 sur 4.
Combien de temps prend la leçon « Tests internes, déploiement progressif et production » ?
La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.
Peux-tu écrire et exécuter du code dans cette leçon React Native Academy ?
Oui. Chaque leçon React Native Academy inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.
Toutes les leçons de ce cours
- Créer un keystore et signer l'AAB
- Configurer la fiche dans la Play Console
- Classification du contenu, règles et confidentialité
- Tests internes, déploiement progressif et production