Flujos de Trabajo de EAS

Una lista de verificación para pipelines YAML que construyen, prueban, envían y actualizan aplicaciones de Expo SDK 57 en la infraestructura de EAS. Trabaja a través de cada elemento antes de llamar a tu tren de versión para que esté listo para producción.

Cómo Usar Esta Lista de Verificación

• Ejecuta Tier 1–2 antes de tu primer workflow:run; Tier 3–5 antes de que la automatización de tienda se ponga en marcha.
• Mantén un flujo de trabajo por intención - pr-quality.yml, preview-pr.yml, store-release.yml - no un mega-archivo.
• Refleja scripts npm de CI Quality Gates - los desarrolladores y los flujos de trabajo llaman a los mismos comandos.
• Vuelve a ejecutar los tiers fallidos después de las correcciones; un eas build local verde no significa que el YAML del flujo de trabajo esté conectado correctamente.

Descripción General de Tiers

Tier 1: Configuración del Proyecto (1–6)

1. Proyecto de EAS vinculado - app.json / app.config.ts contiene extra.eas.projectId después de eas init.

   • Señal: eas workflow:run solicita crear un proyecto interactivamente.
   • Fix: npx eas-cli@latest init en SDK 57; confirma el ID de proyecto generado.
   • Prioridad: P0 - bloquea todas las ejecuciones de flujo de trabajo.

2. Los perfiles de eas.json existen para cada intención - como mínimo preview, production y e2e-test.

   • Señal: Los parámetros de flujo de trabajo params.profile hacen referencia a una clave que falta.
   • Fix: Build Profiles & Flavors.
   • Prioridad: P0.

3. Directorio .eas/workflows/ confirmado - YAML es código fuente, revisado como cambios de aplicación.

   • Señal: Los flujos de trabajo solo existen en la computadora portátil de un ingeniero.
   • Fix: Agrega primero quality-gates.yml; expande desde allí.
   • Prioridad: P0.

4. EXPO_TOKEN cuenta de robot en secretos de CI - no un token de acceso personal vinculado a un desarrollador.

   • Señal: Los flujos de trabajo fallan cuando ese desarrollador está de vacaciones.
   • Fix: Panel de Expo → Access Tokens → usuario máquina; guardar en GitHub / secretos de EAS.
   • Prioridad: P0.

5. CLI de flujo de trabajo probado localmente - npx eas-cli@latest workflow:run .eas/workflows/quality-gates.yml.

   • Señal: La primera ejecución falla en la sintaxis YAML descubierta solo en la nube.
   • Fix: Ejecuta manualmente antes de conectar on: pull_request.
   • Prioridad: P1.

6. Grupo de concurrencia configurado - cancelar ejecuciones supersedidas en empujes rápidos de PR.

   • Señal: Cinco builds idénticas se ponen en cola para un PR.
   • Fix:

concurrency:
  cancel_in_progress: true
  group: ${{ workflow.filename }}-${{ github.ref }}

• Prioridad: P1.

Tier 2: Flujos de Trabajo de Calidad y PR (7–12)

7. Trabajo de calidad personalizado antes de cualquier type: build - lint, typecheck, test en eas/checkout.
   • Señal: Las builds nativas comienzan mientras TypeScript está roto.
   • Fix:

# .eas/workflows/quality-gates.yml
name: Quality Gates
on:
  pull_request:
    branches: [main]
 
jobs:
  quality:
    steps:
      - uses: eas/checkout
      - uses: eas/use_npm_token
      - uses: eas/install_node_modules
      - run: npx expo customize tsconfig.json
      - run: npm run format:check
      - run: npm run lint
      - run: npm run typecheck
      - run: npm run test -- --ci

• Prioridad: P0 en cada PR.

8. needs: [quality] en trabajos de build posteriores - las builds esperan scripts verdes.

   • Señal: build_ios y quality se ejecutan en paralelo.
   • Fix: Agrega array needs en cada trabajo type: build.
   • Prioridad: P0.

9. Disparador de PR coincide con la política de rama - pull_request.branches: [main] o release/*.

   • Señal: Los flujos de trabajo nunca se disparan en forks de equipo o rama base incorrecta.
   • Fix: Alinea con objetivos de protección de rama de GitHub.
   • Prioridad: P1.

10. Perfil de build preview para flujos de trabajo de PR - distribution: internal o simulator / apk según sea necesario.

    • Señal: El flujo de trabajo de PR intenta credenciales production.
    • Fix: Perfil preview separado en eas.json - Internal Distribution.
    • Prioridad: P0 para previews de PR.

11. Trabajo de build genera build_id consumido posteriormente - Maestro y submit hacen referencia al mismo artefacto.

    • Señal: El trabajo de submit llama a --latest en lugar de un ID fijado.
    • Fix:

  build_android:
    needs: [quality]
    type: build
    params:
      platform: android
      profile: preview
 
  maestro_smoke:
    needs: [build_android]
    type: maestro
    params:
      build_id: ${{ needs.build_android.outputs.build_id }}
      flow_path: [".maestro/smoke.yml"]

- **Prioridad:** P0 antes del submit automatizado.

12. El appId de Maestro coincide con los ID de paquete de eas.json - los flujos lanzan la aplicación construida, no Expo Go. - Señal: El trabajo de Maestro tiene éxito localmente pero falla en el flujo de trabajo - appId incorrecto. - Fix: Maestro E2E. - Prioridad: P0 en el primer flujo de trabajo de E2E.

Tier 3: Build, Submit y Release (13–18)

13. Flujo de trabajo de build de producción desencadenado por etiqueta semver - on.push.tags: ["v*"].

    • Señal: Cada merge a main se envía a las tiendas.
    • Fix: Versión impulsada por etiqueta; workflow_dispatch manual para hotfixes.
    • Prioridad: P0.

14. type: build con profile: production y autoIncrement - los números de build avanzan sin editar manualmente plists.

    • Señal: La tienda rechaza versionCode duplicado / número de build.
    • Fix: "autoIncrement": true en el perfil de producción de eas.json.
    • Prioridad: P0.

15. type: submit hace referencia a build_id del trabajo de build emparejado - no --latest.

    • Señal: La tienda recibe una build que QA nunca probó.
    • Fix:

  submit_ios:
    needs: [smoke_ios]
    type: submit
    params:
      platform: ios
      build_id: ${{ needs.build_ios.outputs.build_id }}

- **Prioridad:** P0 - [Automated Store Promotion](./automated-store-promotion.md).

16. Maestro smoke controla submit - al menos login + una ruta crítica de ingresos. - Señal: Submit se ejecuta inmediatamente después de build sin verificación de dispositivo. - Fix: needs: [maestro_smoke] en trabajos de submit. - Prioridad: P0 para promoción automatizada.

17. Los trabajos de submit de iOS y Android se ejecutan en paralelo después de smoke específico de la plataforma - no serializar innecesariamente.

    • Señal: Android espera el procesamiento de iOS TestFlight.
    • Fix: Cadenas de build separadas → smoke → submit por plataforma.
    • Prioridad: P1.

18. Notificación de Slack / correo electrónico en fallo de flujo de trabajo - en el turno lo sabe antes que los usuarios.

    • Señal: El lanzamiento fallido se descubre el lunes por la mañana.
    • Fix: Notificaciones de GitHub o paso personalizado que se publica en webhook.
    • Prioridad: P1.

Tier 4: Flujos de Trabajo de Actualización OTA (19–24)

19. type: update trabajo apunta a canal explícito - production, staging, no default implícito.

    • Señal: El paquete staging se promociona a canal de producción por typo.
    • Fix: Release Channels & Branches.
    • Prioridad: P0.

20. El flujo de trabajo de OTA ejecuta controles de calidad primero - lint/tsc/test igual que las verificaciones de PR.

    • Señal: TypeScript roto se envía vía OTA.
    • Fix: needs: [quality] antes de type: update.
    • Prioridad: P0.

21. Política de runtimeVersion documentada - OTA compatible solo con binarios de tienda coincidentes.

    • Señal: OTA se bloquea en versiones de aplicación más antiguas.
    • Fix: Runtime Version Policy.
    • Prioridad: P0.

22. El mensaje de OTA incluye Git SHA - trazabilidad en el panel de EAS.

    • Señal: No puede correlacionar la actualización con el PR fusionado.
    • Fix: message: ${{ github.sha }} en parámetros de actualización.
    • Prioridad: P1.

23. Flujo de trabajo de rollback documentado y probado - eas update --roll-back o republicación de canal.

    • Señal: El primer incidente de producción no tiene runbook.
    • Fix: Rollback Runbook.
    • Prioridad: P0 antes del primer OTA a producción.

24. Cambios que afectan a native bloqueados del flujo de trabajo exclusivo de OTA - ediciones de complemento de configuración activan flujo de trabajo de build.

    • Señal: OTA importa expo-camera no en binario instalado.
    • Fix: Filtros de ruta o etiqueta de revisión requerida native-change.
    • Prioridad: P0.

Tier 5: Operaciones y Costos (25–30)

25. Tokens de salto documentados - [eas skip] en mensaje de commit para empujes solo de documentación.

    • Señal: El equipo evita los flujos de trabajo por completo porque no pueden saltar.
    • Fix: Documenta en CONTRIBUTING.md; no abuses.
    • Prioridad: P2.

26. Builds preview de PR con puerta de etiqueta o filtro de ruta - no cada typo dispara la build de EAS.

    • Señal: La quema de crédito de EAS excede el presupuesto a mitad de trimestre.
    • Fix: Preview Builds on PRs.
    • Prioridad: P1.

27. Matriz de perfil de build documentada - qué perfil se ejecuta en PR, nightly, release.

    • Señal: El nuevo ingeniero dispara build de producción desde rama de funcionalidad.
    • Fix: Tabla en README o Mobile CI/CD Basics.
    • Prioridad: P1.

28. Secretos rotados en horario - EXPO_TOKEN, clave API de App Store Connect, cuenta de servicio de Play.

    • Señal: La fuga de token requiere revocación de emergencia sin copia de seguridad.
    • Fix: Entrada de calendario de rotación trimestral.
    • Prioridad: P1.

29. Duración del flujo de trabajo monitoreada - calidad + build + Maestro p95 rastreados.

    • Señal: El tren de versión pierde la ventana de viernes silenciosamente.
    • Fix: Tiempos de build del panel de EAS; optimiza caché de install_node_modules.
    • Prioridad: P2.

30. Simulacro de desastre: el Maestro fallido bloquea submit - verificado en staging, no asumido.

    • Señal: El trabajo de submit tiene cableado de needs suelto; el fallo de smoke se ignora.
    • Fix: Intencionalmente falla un flujo en flujo de trabajo de staging trimestralmente.
    • Prioridad: P1.

Referencia: Tipos de Trabajos

Bosquejo de Flujo de Trabajo de Versión Completo

# .eas/workflows/store-release.yml
name: Store Release
on:
  push:
    tags: ["v*"]
 
jobs:
  quality:
    steps:
      - uses: eas/checkout
      - uses: eas/install_node_modules
      - run: npm run lint && npm run typecheck && npm run test -- --ci
 
  build_android:
    needs: [quality]
    type: build
    params: { platform: android, profile: production }
 
  smoke_android:
    needs: [build_android]
    type: maestro
    params:
      build_id: ${{ needs.build_android.outputs.build_id }}
      flow_path: [".maestro/smoke.yml"]
 
  submit_android:
    needs: [smoke_android]
    type: submit
    params:
      platform: android
      build_id: ${{ needs.build_android.outputs.build_id }}
 
  update_production:
    needs: [submit_android]
    type: update
    params:
      channel: production
      message: "Post-release OTA sync ${{ github.sha }}"

FAQs

npx eas-cli@latest workflow:run .eas/workflows/quality-gates.yml

Relacionado

• Mobile CI/CD Basics - carriles de PR vs versión vs nightly
• GitHub Actions + EAS - configuración de CI híbrida
• Automated Store Promotion - submit controlado después de smoke
• EAS Build Basics - perfiles y primera build
• OTA Updates Basics - restricciones de OTA
• Maestro E2E - archivos de flujo y perfil e2e-test
• CI Quality Gates - scripts que los flujos de trabajo deben llamar

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).