Busca en todas las páginas de la documentación
Un resumen condensado de las 25 prácticas de entrega empresarial más importantes para equipos móviles de Expo SDK 57 - un calendario para iOS, Android, backend y OTA, extraído de cada página de esta sección.
Ejecuta dos relojes de entrega: Binario de tienda (nativo) y paquete OTA (JS) - nunca confundas qué ruta toma un cambio - Conceptos básicos de entrega móvil.
Un calendario compartido de lanzamiento: Mobile, backend, QA y soporte ven el mismo tren - no etiquetas ad-hoc de viernes - Calendario del tren de lanzamiento.
Declara la ruta de entrega en cada PR: Solo JS → OTA; cambio nativo → se requiere eas build - las compuertas de CI de huella digital lo hacen cumplir.
Establece una política de runtimeVersion explícita: appVersion, fingerprint o sdkVersion - coherente en compilaciones y actualizaciones - Política de versión de tiempo de ejecución.
Alinea el canal de eas.json con el objetivo de eas update: Los binarios de producción en channel: production reciben actualizaciones publicadas en el mismo canal.
Fija build_id desde QA para enviar: El artefacto en el que QA aprobó es el que reciben las tiendas - sin reconstrucción entre puertas - Promoción automática de tienda.
Congela OTA a producción durante RC de tienda: Previene la desviación de JS entre la aprobación de QA y eas submit - el carril de corrección de emergencia se reabre después de que el binario esté en vivo.
Backend se implementa antes de OTA móvil que depende de él: API activa con compatibilidad hacia atrás; los flags ocultan la nueva UI hasta que ambos lados estén listos.
Los flags de características están desactivados por defecto: Los interruptores de parada remota desacoplan la entrega en vivo del binario de la característica visible - Flags de características en móvil.
Cachea flags localmente: El endpoint de configuración muerto no debe bloquear los inicios en frío - valores predeterminados seguros cuando lo remoto es inalcanzable.
Vista previa empapa antes de OTA de producción: Mínimo 24h en rutas de ingresos - los lanzamientos no son un sustituto de QA - Canales de lanzamiento y ramas.
Canario OTA al 10% antes del 100%: eas update --rollout-percentage=10 con compuertas de monitoreo - Canario OTA y Azul-Verde.
Flag desactivado primero en incidente; reversión de OTA segundo: Segundos vs minutos - los defectos del paquete necesitan republicación de canal - Manual de reversión.
Registra el último ID de actualización conocido bueno por lanzamiento: Reversión sin adivinar - simulacro trimestral en canal de vista previa.
El lanzamiento en etapas de tienda es el valor predeterminado: Porcentaje en etapas de Play y lanzamiento por fases de ASC - 100% del primer día es la excepción - Mejores prácticas de operaciones de tienda.
Go/No-Go antes de cada envío de tienda: Lista de verificación completa antes de la reunión; decisión registrada con aprobadores nombrados - Lista de verificación de lanzamiento y Go/No-Go.
Matriz de dispositivo físico en cada RC: Los simuladores pierden push, biometría, IAP y firma - la aprobación de QA nombra dispositivos probados.
Pruebas de contrato en comprobaciones de PR: Desviación de API detectada antes del día del calendario - backend y móvil permanecen compatibles.
Divide métricas DORA por ruta: LT-OTA, LT-Store, DF-OTA, DF-Store - la mezcla oculta cuellos de botella - Métricas DORA para móvil.
Cuenta reversiones en la tasa de cambios fallidos: La reversión de OTA, el bloqueo de lanzamiento y la corrección de emergencia de tienda son todos fracasos - la CFR de vanidad no ayuda a nadie.
Reporta MTTR por nivel: Flag desactivado (< 5m), reversión de OTA (< 15m), corrección de emergencia de tienda (días) - nunca los promedies.
Las semanas solo OTA aún necesitan disciplina: Promoción de canal, tarjetas de reversión y vista previa de empapes - saltar tienda no es saltar proceso.
Las aplicaciones de marca blanca obtienen canales separados: Nunca compartas un canal de producción entre IDs de paquete - Perfiles de compilación y sabores.
Automatiza canalizaciones de lanzamiento; compuertas humanas promoción: EAS Workflows compilación y actualización; EM aprueba Go/No-Go - Flujos de trabajo de EAS.
Postmortem de cada reversión de producción: Actualiza lista de verificación, umbrales canarios y plantilla de calendario dentro de cinco días hábiles - la entrega mejora a través de incidentes, no a pesar de ellos.
expo-updates y runtimeVersion en el siguiente lanzamiento de tienda.Gerente de ingeniería o capitán de lanzamiento - responsable. Mobile, backend, QA y soporte son consultados. El calendario es un documento viviente vinculado a la epopeya de lanzamiento, no una hoja de cálculo de una sola vez.
No. OTA no puede agregar módulos nativos, permisos, actualizaciones de SDK o derechos. DF-OTA alto con DF-Store bajo es saludable - no es un fracaso en el envío de compilaciones de tienda.
EAS Build + EAS Update + calendario compartido + build_id fijado + vista previa de empape + tarjeta de reversión. Agrega LaunchDarkly y paneles DORA a medida que crece el volumen.
Versiones de pila: Esta página fue escrita para React 19.2.3, React Native 0.86.0 y Expo SDK 57 (
expo~57.0.4).
Revisado por Chris St. John·Última actualización: 16 jul 2026