Busca en todas las páginas de la documentación
Diez ejemplos para coordinar lanzamientos de tiendas nativas con trenes OTA de JavaScript - la base operacional que los equipos móviles empresariales necesitan antes de escalar más allá de un ingeniero etiquetando compilaciones del viernes.
La entrega empresarial supone que ya tienes EAS Build y EAS Update configurados:
npx create-expo-app@latest EnterpriseDelivery --template blank-typescript@sdk-57 --yes
cd EnterpriseDelivery
npx expo install expo-updates
npx eas init
npx eas update:configure
npx eas build:configureConfirma el pin de pila:
{
"dependencies": {
"expo": "~57.0.4",
"react": "19.2.3",
"react-native": "0.86.0"
}
}Herramientas: Estos ejemplos tienen como objetivo Expo SDK 57 (
expo~57.0.4), React Native 0.86.0 y React 19.2.3. Lee Conceptos básicos de EAS Build y Conceptos básicos de OTA Updates antes de coordinar trenes.
Cada decisión de lanzamiento empresarial comienza con qué reloj le pertenece el cambio:
Clock A - Binario de tienda (eas build + eas submit)
Cambios: módulos nativos, bumps de SDK, permisos, derechos, iconos
Cadencia: tren de lanzamiento quincenal o mensual
Reversión: nueva versión de tienda (horas a días)
Clock B - Bundle OTA (eas update)
Cambios: JS, TypeScript, activos, copia - mismo runtimeVersion que Clock A
Cadencia: diaria a semanal entre trenes de tienda
Reversión: eas update:rollback (minutos)| Reloj | Punto de entrada CI | Propietario | Impacto del usuario si está fuera de tiempo |
|---|---|---|---|
| A | eas build en etiqueta | Plataforma móvil | Bloqueo en el lanzamiento, rechazo de tienda |
| B | eas update en merge | Característica móvil | Interfaz de usuario incorrecta, errores de JS en binario antiguo |
Usa una tabla de decisión simple en cada plantilla de PR:
| Cambio | Reloj | Por qué |
|---|---|---|
| Corrección de color de botón | B (OTA) | JavaScript puro |
Nueva dependencia expo-camera | A (tienda) | Módulo nativo - cadenas de permisos |
| El cliente API lee nuevo campo opcional | B (OTA) | Lector tolerante en JS |
| Bump de Hermes / SDK 57 | A (tienda) | Cambio de runtime nativo |
| Intercambiar activo de imagen hero | B (OTA) | Activo empaquetado |
Agregar NSCameraUsageDescription | A (tienda) | Info.plist en binario |
# Fragmento de lista de verificación de PR - pegar en .github/pull_request_template.md
## Ruta de entrega
- [ ] JS-only → preview soak → production OTA
- [ ] Native change → eas build required; OTA blocked until new binary shipsRelacionado: Conceptos básicos de OTA Updates - qué OTA puede y no puede cambiar
runtimeVersion es el contrato entre Clock A y Clock B:
// app.config.ts
import type { ExpoConfig } from "expo/config";
const config: ExpoConfig = {
name: "EnterpriseDelivery",
slug: "enterprise-delivery",
version: "2.5.0",
runtimeVersion: {
policy: "appVersion", // la línea "2.5.0" recibe solo OTAs 2.5.x
},
updates: {
url: "https://u.expo.dev/<project-id>",
},
ios: { bundleIdentifier: "com.example.enterprisedelivery" },
android: { package: "com.example.enterprisedelivery" },
};
export default config;// eas.json - canal incrustado en tiempo de compilación
{
"build": {
"production": {
"channel": "production",
"environment": "production"
}
}
}runtimeVersion: 2.5.0 reciben OTAs publicadas solo para 2.5.0version a 2.6.0 sin una nueva compilación de tienda deja a los usuarios de 2.5.0 con JS antiguofingerprint y sdkVersionCada binario de producción debe escuchar en el mismo canal en el que publiques:
# Compilar binario de producción - canal integrado en tiempo de compilación
eas build --profile production --platform all --non-interactive
# OTA debe dirigirse al mismo canal
eas update --channel production --environment production \
--message "fix: checkout total rounding"# Verifica la alineación antes de cada OTA de producción
eas channel:view production
# Confirma que el canal apunta a la rama de producción y runtimeVersion coincide con app.configLos equipos empresariales ejecutan un calendario compartido - no hojas de cálculo separadas de iOS, Android y JS:
# Lanzamiento 2.5.0 - Semana del 2026-07-14
## Clock A (tienda)
- Jue S1: congelación de código 18:00 UTC
- Vie S1: etiqueta v2.5.0; eas build de producción; envío controlado
- Lun S2: Play escalonado 10% - 50%
- Mié S2: Lanzamiento escalonado de ASC 100%
## Clock B (OTA)
- Lun-Mié S1: OTA solo a canal de vista previa (detrás de flags)
- Jue S1: congelar OTA a producción hasta que se firme RC de tienda
- Mié S2: carril de hotfix OTA abierto si runtimeVersion no cambia
## Dependencias
- [ ] API v3 en prod - @backend - Jue S1
- [ ] Flag de característica checkout_v3 al 0% - @mobile - Vie S1runtimeVersion sea estableEl artefacto que QA probó debe ser el artefacto que reciben las tiendas:
# El pipeline de lanzamiento registra build_id en ticket
eas build --profile production --platform ios --non-interactive
# build_id: abc123-def456-...
# QA aprueba abc123 - nunca reconstruya antes de enviar
eas submit --platform ios --id abc123-def456-... --non-interactive# .github/workflows/release.yml - enviar ID fijo desde salida de workflow
- name: Submit iOS (pinned build)
run: eas submit --platform ios --id ${{ needs.build.outputs.ios_build_id }} --non-interactive--latest es solo para emergencias - documenta cuándo está permitidoJS que llama a una nueva API no debe enviarse OTA hasta que el backend esté en vivo:
Orden incorrecta: OTA se envía el lunes - API se despliega el jueves - 3 días de 404
Orden correcta: API se despliega el jueves (compatible hacia atrás) - OTA se envía el viernes// src/api/checkout.ts - lector tolerante hasta que el flag se ramifique
export async function fetchCheckoutConfig(): Promise<CheckoutConfig> {
const res = await api.get("/v3/checkout/config");
if (res.status === 404) {
return api.get("/v2/checkout/config"); // alternativa para ruta antigua
}
return res.json();
}Los binarios de tienda pueden estar en revisión durante días mientras JS se envía diariamente - los flags desacoplan en vivo de visible:
Día 1: eas build envía v2.5.0 a TestFlight - flag checkout_v3 APAGADO
Día 3: eas update envía interfaz de usuario de checkout - todavía oculta detrás de flag
Día 5: App Review aprueba; comienza el lanzamiento escalonado - flag 0%
Día 7: OTA - flag se incrementan al 10% de cohorte interna
Día 10: flag 100% después de que las métricas pasenCuando el tren es solo JS, omite Clock A pero mantén disciplina:
# Lun - merge detrás de flags; publica vista previa
eas update --channel preview --environment preview --message "feat: loyalty points UI"
# Mar - QA soak en binario de vista previa (mismo runtimeVersion que producción)
# Mié - lanzamiento escalonado de producción
eas update --channel production --environment production \
--rollout-percentage=10 --message "rollout: loyalty @ 10%"
# Jue - monitorea Sentry; revierte si crash-free cae
# Vie - 100% si las métricas se mantienenDocumenta la reversión antes de necesitarla - los incidentes empresariales se mueven más rápido con tarjetas pre-escritas:
| Reloj | Disparador | Acción | ETA |
|---|---|---|---|
| B (OTA) | Crash-free -2% después de publicar | eas update:rollback - flag apagado | < 15 min |
| B (OTA) | Éxito de pago -1% | Flag apagado primero; reversión segundo | < 10 min |
| A (tienda) | Bloqueo nativo en el lanzamiento | Detener lanzamiento escalonado; promover versión anterior | 1-24 hr |
| A (tienda) | Rechazo de tienda | Corregir binario; reenviar - OTA no puede reparar nativo | días |
# Tarjeta de reversión OTA - rellenar por lanzamiento
eas update:list --branch production --limit 3
# Último conocido como bueno: <update-group-id>
eas update:rollbackSí, si runtimeVersion coincide con el binario en revisión y la OTA no cambia el comportamiento que los revisores probarán. Mantén OTAs de producción detrás de flags hasta la aprobación - los revisores pueden probar una compilación que recibe una OTA en el lanzamiento.
Quincenal es común para aplicaciones de consumo; mensual para industrias reguladas. OTA llena el vacío entre trenes - diario o semanal para correcciones de JS. Adapta la cadencia al riesgo de revisión de tienda y ventanas de dependencia de backend.
Gerente de ingeniería o capitán de lanzamiento - responsable. Se consulta a mobile, backend, QA y soporte. El calendario vive en un documento compartido o epopeya de Jira, no en el cuaderno de un ingeniero.
Un eas update sirve a ambas plataformas cuando comparten runtimeVersion y canal. Los envíos de tienda siguen siendo por plataforma - EAS Submit.
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