Configurar EAS Build para entornos de producción

Concepto clave

EAS Build es el servicio de construcción en la nube de Expo que automatiza el proceso de compilación de aplicaciones para iOS y Android. Imagina que eres un arquitecto que diseña un edificio: EAS Build es como tener un equipo de construcción especializado que toma tus planos (código fuente) y los transforma en estructuras completas (binarios de aplicación) listas para habitar, sin que tú tengas que manejar grúas o mezcladoras. En lugar de configurar máquinas locales complejas con Xcode y Android Studio, delegas este trabajo pesado a servidores optimizados que garantizan consistencia y reproducibilidad.

Para entornos de producción, EAS Build se convierte en tu línea de ensamblaje confiable. Cada compilación pasa por un proceso estandarizado que incluye gestión de dependencias, compilación nativa, firma de aplicaciones y generación de artefactos listos para distribución. Esto elimina el "funciona en mi máquina" y asegura que cada release se construya exactamente igual, ya sea para TestFlight, Google Play o despliegues internos. La analogía perfecta es una fábrica de automóviles: tus desarrolladores diseñan el modelo (código), y EAS Build opera la cadena de montaje que produce vehículos idénticos y verificados.

Cómo funciona en la práctica

Configurar EAS Build para producción sigue un flujo sistemático. Primero, instala la CLI globalmente con npm install -g eas-cli y autentícate usando eas login. Luego, en tu proyecto Expo, ejecuta eas build:configure para generar el archivo eas.json que define tus entornos. Este archivo es el cerebro de tu configuración, donde especificarás diferencias entre desarrollo, staging y producción.

Un ejemplo práctico: supongamos que necesitas diferentes variables de entorno para producción. Crearás perfiles de compilación separados en eas.json, cada uno con su propio conjunto de configuraciones. Para producción, activarás la minificación, deshabilitarás el modo debug y configurarás credenciales de firma específicas. El proceso completo implica: 1) Definir perfiles en eas.json, 2) Configurar secrets para credenciales sensibles, 3) Ejecutar eas build --platform all --profile production, 4) Monitorear el build en dashboard.expo.dev, y 5) Descargar o distribuir los artefactos resultantes.

Codigo en accion

Veamos la configuración base y cómo evoluciona para producción. Comenzamos con un eas.json básico generado automáticamente:

{
  "cli": {
    "version": ">= 3.0.0"
  },
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal"
    },
    "preview": {
      "distribution": "internal"
    },
    "production": {}
  },
  "submit": {
    "production": {}
  }
}

Ahora, lo transformamos para un entorno de producción robusto con optimizaciones y variables específicas:

{
  "cli": {
    "version": ">= 3.0.0"
  },
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal",
      "android": {
        "buildType": "apk"
      }
    },
    "preview": {
      "distribution": "internal",
      "android": {
        "buildType": "app-bundle"
      },
      "ios": {
        "simulator": true
      }
    },
    "production": {
      "autoIncrement": true,
      "distribution": "store",
      "android": {
        "buildType": "app-bundle",
        "gradleCommand": ":app:bundleRelease"
      },
      "ios": {
        "enterpriseProvisioning": "universal",
        "autoIncrement": "buildNumber"
      },
      "env": {
        "API_URL": "https://api.tuapp.com",
        "LOG_LEVEL": "error"
      }
    }
  },
  "submit": {
    "production": {
      "android": {
        "serviceAccountKeyPath": "./google-key.json",
        "track": "production"
      },
      "ios": {
        "appleId": "tu@email.com",
        "ascAppId": "1234567890"
      }
    }
  }
}

Nota cómo el perfil production activa autoIncrement para versionado automático, usa distribution: "store" para builds publicables, especifica comandos Gradle optimizados y define variables de entorno críticas. El bloque submit configura el despliegue automático a stores.

Errores comunes

• Credenciales faltantes o incorrectas: Olvidar configurar secrets para certificados iOS o clave de Google Play resulta en builds fallidos. Solución: Usa eas credentials para gestionarlas y verifica con eas build:list antes de compilar.
• Variables de entorno no inyectadas: Definir variables en .env pero no en eas.json causa valores undefined en producción. Solución: Declara todas las variables necesarias en el bloque env del perfil production y usa eas secret:create para datos sensibles.
• Perfiles de build mal estructurados: Mezclar configuraciones de desarrollo y producción lleva a builds inconsistentes. Solución: Mantén perfiles separados y claramente diferenciados, como se muestra en el ejemplo anterior.
• Ignorar el cache de EAS: No aprovechar la cache aumenta tiempos de build y costos. Solución: Configura cache en eas.json para node_modules y carpetas de dependencias nativas.
• No validar artifacts antes de distribuir: Subir builds sin probarlos en dispositivos reales puede generar crashes en producción. Solución: Usa eas build:run para instalar builds en dispositivos conectados o emuladores antes del release.

Checklist de dominio

1. Tengo configurados al menos tres perfiles en eas.json: development, preview y production con diferencias claras.
2. He almacenado todas las credenciales sensibles (iOS certificates, Google Service Account) usando eas secret:create.
3. Las variables de entorno específicas de producción están definidas en el bloque env del perfil production.
4. He ejecutado exitosamente un build de producción con eas build --platform ios --profile production y descargado el artifact.
5. Comprendo cómo funciona autoIncrement para versionado automático y lo tengo configurado en producción.
6. He configurado el bloque submit para desplegar automáticamente a App Store Connect y Google Play Console.
7. Puedo monitorear y depurar builds fallidos usando el dashboard de EAS y logs detallados.

Configurar un pipeline de EAS Build para despliegue continuo

En este ejercicio, transformarás un proyecto Expo existente para implementar un pipeline de compilación automatizado para producción. Sigue estos pasos:

1. Clona o usa tu proyecto Expo actual. Asegúrate de tener la última versión de EAS CLI instalada globalmente.
2. Ejecuta eas build:configure y modifica el archivo eas.json generado para incluir tres perfiles: development (con developmentClient activado), staging (para pruebas internas), y production (optimizado para stores).
3. En el perfil production, configura:
   • autoIncrement: true
   • distribution: "store"
   • Variables de entorno API_URL y ENV con valores de producción
   • Comando Gradle específico para release
4. Usa eas secret:create para almacenar al menos una credencial simulada (puede ser un string de prueba) y referenciarla en tu perfil production.
5. Ejecuta un build de prueba para Android en perfil production con eas build --platform android --profile production y verifica que se complete exitosamente.
6. Configura un trigger automático en tu CI/CD (puede simularse con un script local) que ejecute el build de producción cuando se haga push a la rama main.

Pistas

• Recuerda que las variables en eas.json sobreescriben las de .env, define todas las necesarias para producción.
• Usa eas build:list para ver el estado de tus builds y depurar problemas.
• Para simular CI/CD, crea un script bash que verifique la rama y ejecute eas build automáticamente.

Evalua tu comprension

Completa el quiz interactivo de arriba para ganar XP.

Práctica acompañada: Una app que cabe en tu día

Un proyecto pequeño con React Native y Expo. Usa este cuaderno como práctica complementaria de la ruta; el material original de la lección continúa siendo tu referencia.

Práctica: prueba en cuatro condiciones

Completa el flujo con una imagen vertical, una horizontal, cancelando el selector y negando el permiso. Comprueba que la aplicación conserva proporciones y que ningún control queda fuera de alcance. Repite al volver del fondo y al cambiar el tamaño del texto.

Si tu proyecto permite guardar la imagen, verifica por separado el permiso y el resultado de guardado. No muestres «Guardado» antes de que la operación termine. Usa archivos de prueba propios. Para comparar versiones, conserva capturas con el mismo dispositivo, orientación y tamaño de letra.

Comprueba tu entrega

Entrega el repositorio con instrucciones, la lista de versiones y la matriz de dispositivos. Incluye una captura de cada estado y un video propio breve que muestre el recorrido entero, incluida la cancelación. No hace falta publicar una app para demostrar este aprendizaje.

• Abrir el cuaderno ilustrado de 7 páginas
• Descargar PDF, ejercicios y plantillas de esta ruta
• Expo: tutorial oficial · recurso externo