内部テスト、段階的リリース、本番公開

The Four Release Tracks

// 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 launch

Setting Up Internal Testing

// 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 paths

Creating a Closed Testing Track

// 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 > Confirm

Open Testing (Public Beta)

// 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 pool

Promoting to Production

// 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 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 rollout

Monitoring Crashes with Android Vitals

// 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

// 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 reviews

Version Code Increment Strategy

// 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

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

// 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 fixes

Quick Check

Lesson Recap