Mejores Prácticas de Actualizaciones OTA

Un resumen condensado de las 25 mejores prácticas más importantes extraídas de cada página en esta sección.

1. OTA es solo JS y assets: Los módulos nativos, plugins de configuración, permisos, derechos, upgrades de SDK e iconos de aplicación requieren eas build y envío a la tienda - OTA no puede agregar símbolos nativos.

2. Establece una política explícita de runtimeVersion: Usa appVersion, nativeVersion o fingerprint consistentemente en app.config - documenta la opción en README y nunca mezcles políticas entre flavors sin un ADR.

3. Coincide con el runtime en build y update: El runtimeVersion resuelto por eas build debe ser igual a lo que eas update apunta - verifica con npx expo config --type public antes de cada publicación.

4. Cambia de runtime cuando los cambios nativos ocurren: Nueva dependencia nativa, edición de plugin o cambio de cadena de permiso significa nuevo build de tienda y nueva línea de runtime - no hagas OTA en JS que importa módulos nativos faltantes.

5. Configura updates.url y projectId: Ejecuta eas update:configure después de eas init - la falta de updates.url desactiva expo-updates silenciosamente en builds de lanzamiento.

6. Conecta los headers de canales a los perfiles de build: updates.requestHeaders["expo-channel-name"] debe coincidir con eas.json channel para cada perfil - impulsa desde EAS_BUILD_PROFILE en app.config dinámico.

7. Usa eas update --environment siempre: En SDK 55+, los update runners ignoran .env local - pasa --environment production (o preview) para que los OTA bundles coincidan con las variables de entorno del build.

8. Nombra canales para entornos: development, preview, staging, production - no nombres de ingenieros; asigna canales a audiencias en docs/release-channels.md.

9. Flujo de promoción lineal: development → preview (QA) → production - no saltes preview para pagos, autenticación o cambios de checkout independientemente del tamaño del diff.

10. Builds de vista previa para aprobación de OTA: QA prueba en binarios del perfil preview de EAS, no en Expo Go - Expo Go no puede recibir tu configuración de actualización de producción.

11. CI-only publicación de producción: Prefiere flujos de trabajo etiquetados de GitHub Actions para eas update --channel production - la publicación desde laptop es vidrio roto con aprobador secundario y postmortem.

12. Registra el ID de actualización anterior más conocido: Cada ticket de lanzamiento de producción almacena el ID de bundle anterior para eas update:rollback o eas update:republish - los rollbacks sin esto son adivinanza.

13. Define los triggers de rollback antes del lanzamiento: Crash-free drop, payment success drop y umbrales de auth error spike con propietarios - ver Release & OTA Rules Tier 4.

14. Practica rollback trimestralmente en preview: Ejecuta eas update:rollback en el canal preview en un drill - apunta a menos de 15 minutos desde la decisión hasta la verificación de channel head.

15. Gate de JS dependiente de código nativo con flags: Kill switches remotos más Application.nativeApplicationVersion checks previenen crashes hasta que la adopción de tienda cruza tu umbral.

16. Log updateId en análisis de producción: Updates.updateId, runtimeVersion y channel al inicio de sesión - el soporte y la respuesta a incidentes dependen de saber qué bundle se está ejecutando.

17. checkAutomatically ON_LOAD con fallback 0: Verifica en arranque en frío sin bloquear el lanzamiento en redes lentas - sintoniza el UX de recarga por separado mediante la API del cliente de expo-updates.

18. Reconstruye después de la primera configuración de updates: Agregar wiring de expo-updates requiere un nuevo binario nativo - eas update por sí solo no habilita updates en instalaciones antiguas.

19. Trata las regresiones de tamaño de bundle como lanzamientos: Los OTA bundles grandes dañan TTI - compara la salida de Metro antes de publicación de producción y vincula a las reglas de presupuesto de rendimiento.

20. Contratos de API compatibles hacia atrás: Los usuarios móviles saltan updates - el JS enviado OTA debe tolerar respuestas de API más antiguas hasta que la adopción de tienda sea alta; ejecuta contract tests en CI.

21. Migraciones seguras de almacenamiento local: Los cambios de esquema de MMKV y SQLite necesitan rutas de upgrade probadas desde el bundle de producción anterior - las migraciones malas cierran las instalaciones y necesitan rollback.

22. Rollouts escalonados en producción: Usa --rollout-percentage o eas channel:rollout después de soak de preview - monitorea crash y métricas de pago en cada paso antes de 100%.

23. Tag Sentry con updateId: Segmenta reportes de crash por bundle durante rollouts - sin tags de cohorte, los rollouts de porcentaje son ciegos.

24. Rastrear distribución de runtime semanalmente: Porcentaje de usuarios por runtimeVersion - los binarios antiguos dejan de recibir OTAs; aplica una versión nativa mínima cuando la seguridad lo requiere.

25. Checklist de dos pistas de lanzamiento: Checklist de envío de tienda para cambios nativos y checklist de OTA para soak de preview, flags, ID de rollback y dashboards - adjunta ambos a cada ticket de lanzamiento.

Preguntas Frecuentes

Relacionado

• OTA Updates Basics - límites OTA vs tienda
• expo-updates Configuration - cookbook de app.config
• Release Channels & Branches - flujo de trabajo de promoción
• Rollback Runbook - republish de channel en minutos
• Runtime Version Policy - selección de política
• Staged Rollouts - rollouts de porcentaje y monitoreo
• expo-updates (Client API) - client check/fetch/reload
• EAS Build Basics - binarios que reciben updates
• Release & OTA Rules - checklist de aplicación de equipo

Versiones de Stack: Esta página fue escrita para React 19.2.3, React Native 0.86.0 y Expo SDK 57 (expo ~57.0.4).