Conceptos básicos de CI/CD móvil

10 ejemplos para entender comprobaciones de PR, canalizaciones de lanzamiento y compilaciones nocturnas para aplicaciones de Expo SDK 57 - 7 básicos y 3 intermedios.

Requisitos previos

CI/CD para React Native difiere de web: envías binarios nativos (compilaciones de tienda) y opcionalmente paquetes de JavaScript OTA (Conceptos básicos de actualizaciones OTA). Las compilaciones en la nube vía Conceptos básicos de EAS Build mantienen las claves de firma fuera de los portátiles.

npx create-expo-app@latest ShipApp --template blank-typescript
cd ShipApp
npx expo install eas-cli --save-dev
npx eas-cli@latest build:configure

Estandariza los scripts que CI llamará:

{
  "scripts": {
    "lint": "expo lint",
    "typecheck": "tsc --noEmit",
    "test": "jest",
    "format:check": "prettier --check ."
  }
}

Tooling: Estos ejemplos están orientados a Expo SDK 57 (expo ~57.0.4), React Native 0.86.0, y React 19.2.3. Los fragmentos E2E asumen compilaciones dev o preview - no solo Expo Go.

Ejemplos básicos

1. Tres tipos de canalizaciones

Los equipos móviles ejecutan tres carriles de automatización distintos con diferentes objetivos de velocidad, costo y radio de acción.

┌─────────────────────────────────────────────────────────────┐
│ Comprobaciones de PR │ Cada PR  │ 2–8 min  │ Bloquear fusión │
├──────────────────────┼──────────┼──────────┼────────────────┤
│ Canalización de lanz.│ Tag/main │ 20–60 min│ Tienda + OTA    │
├──────────────────────┼──────────┼──────────┼────────────────┤
│ Nocturna             │ Cron 02:00│ 30–90 min│ Señal desviación│
└─────────────────────────────────────────────────────────────┘

• Las comprobaciones de PR fallan rápido - sin compilación nativa hasta que TypeScript y pruebas unitarias pasen
• Las canalizaciones de lanzamiento producen el mismo artefacto que QA aprobó y que reciben las tiendas
• Las nocturnas detectan "PRs verdes, rotos juntos" cuando veinte ramas llegan durante la noche

Relacionado: Compuertas de calidad de CI - script que llaman las comprobaciones de PR

2. Comprobaciones de PR - Qué se ejecuta en cada solicitud de fusión

La automatización de PR responde: "¿Es seguro fusionar este diff?" - no "¿Está listo para la App Store?"

# .github/workflows/pr-checks.yml
name: PR Checks
on:
  pull_request:
    branches: [main]
 
jobs:
  quality:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20, cache: npm }
      - run: npm ci
      - run: npx expo customize tsconfig.json
      - run: npm run format:check
      - run: npm run lint
      - run: npm run typecheck
      - run: npm run test -- --ci

• Se ejecuta en cada push a un PR abierto - los desarrolladores obtienen retroalimentación antes de la revisión
• Sin EAS build en cada PR a menos que las compilaciones preview sean explícitamente presupuestadas (Compilaciones preview en PRs)
• La protección de rama requiere la comprobación quality - política, no sistema de honor
• Mismos comandos localmente: npm run lint && npm run typecheck && npm test

Relacionado: Conceptos básicos de pruebas móviles - capas de pirámide que cubren las comprobaciones de PR

3. Canalización de lanzamiento - Etiqueta a binario de tienda

La automatización de lanzamiento responde: "Compila y envía la versión que etiquetamos."

# .github/workflows/release.yml
name: Release
on:
  push:
    tags: ["v*"]
 
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: expo/expo-github-action@v8
        with:
          eas-version: latest
          token: ${{ secrets.EXPO_TOKEN }}
      - run: npm ci
      - run: npm run typecheck && npm run test -- --ci
      - run: eas build --profile production --platform all --non-interactive

// eas.json (extracto)
{
  "build": {
    "production": {
      "autoIncrement": true,
      "channel": "production"
    }
  }
}

• Desencadena en etiquetas semver de Git (v2.4.0) - etiqueta ↔ trazabilidad de binarios
• EXPO_TOKEN cuenta robot - nunca contraseñas personales en CI (GitHub Actions + EAS)
• Perfil production se mapea a credenciales de firma de tienda en EAS
• QA prueba el ID de compilación de esta canalización - no un archivo de portátil

Relacionado: Perfiles de compilación y sabores - preview vs production

4. Compilaciones nocturnas - Detecta desviación de integración

Cuando el volumen de PR es alto, las comprobaciones verdes individuales ocultan fallos de integración entre ramas. Las nocturnas se ejecutan en un horario sin bloquear fusiones.

# .github/workflows/nightly.yml
name: Nightly Integration
on:
  schedule:
    - cron: "0 6 * * 1-5"  # lunes-viernes 06:00 UTC
  workflow_dispatch:
 
jobs:
  nightly:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with: { ref: main }
      - uses: expo/expo-github-action@v8
        with:
          eas-version: latest
          token: ${{ secrets.EXPO_TOKEN }}
      - run: npm ci
      - run: npx expo-doctor
      - run: npm run test -- --ci
      - run: eas build --profile preview --platform android --non-interactive

• Canal de alertas (#mobile-ci) en caso de fallo - no bloques fusiones durante el día
• Incluye npx expo-doctor - detecta desviación de SDK que nadie tocó en los PRs de hoy
• Compila una plataforma nocturna si los créditos son limitados; rota iOS/Android semanalmente
• Combina con pruebas de contrato contra APIs de staging (Pruebas de contrato para APIs)

5. Comprobaciones de PR vs compilaciones preview

No todo PR necesita un binario nativo. Separa compuertas rápidas de compilaciones preview opcionales.

# Vista previa controlada por etiqueta - ahorra créditos de EAS
on:
  pull_request:
    types: [labeled]
jobs:
  preview:
    if: contains(github.event.pull_request.labels.*.name, 'needs-preview')
    # ... eas build --profile preview

• Predeterminado: solo compuertas de calidad - preview en etiqueta o filtro paths para directorios que impacten nativos
• Las compilaciones preview se instalan vía código QR en dispositivos reales - ver Compilaciones preview en PRs
• Documenta la etiqueta en CONTRIBUTING.md para que los diseñadores sepan cuándo agregar needs-preview

6. OTA en el tren de lanzamiento

Las correcciones solo JS envían vía eas update dentro de la canalización de lanzamiento - los cambios nativos aún necesitan eas build.

# .eas/workflows/release-ota.yml (extracto)
jobs:
  quality:
    steps:
      - uses: eas/checkout
      - uses: eas/install_node_modules
      - run: npm run typecheck && npm run test -- --ci
 
  update_production:
    needs: [quality]
    type: update
    params:
      channel: production
      message: ${{ github.sha }}

• OTA se ejecuta después de los mismos scripts de calidad que las comprobaciones de PR
• runtimeVersion debe coincidir con el binario de tienda que los usuarios instalaron - Política de versión de runtime
• Nunca OTA un paquete que importe un módulo nativo ausente del binario instalado
• Ruta de retorno: eas update --roll-back - Runbook de retorno

7. Promoción de artefactos - Mismo binario CI a tienda

El anti-patrón: QA prueba una compilación de portátil; las tiendas reciben una compilación en la nube diferente.

❌ Compilación de portátil → Aprobación de QA → Recompilar en CI → Tienda
✅ ID de compilación de EAS abc123 → Aprobación de QA → eas submit --id abc123 → Tienda

# Promueve la compilación exacta que QA probó
eas submit --platform ios --id <BUILD_ID> --non-interactive
eas submit --platform android --id <BUILD_ID> --non-interactive

• Almacena IDs de compilación en notas de lanzamiento e hilos de Slack
• eas submit --latest es conveniente pero riesgoso si una compilación más nueva se encoló después de QA
• Promoción automática de tienda compuertas submit en Maestro smoke

Relacionado: EAS Submit - Entrega de App Store Connect y Play Console

Ejemplos intermedios

8. Disparadores de PR conscientes de monorepo

Los monorepos Turborepo no deben ejecutar CI móvil cuando solo el sitio de marketing cambió.

on:
  pull_request:
    paths:
      - "apps/mobile/**"
      - "packages/ui/**"
      - "package-lock.json"

# O acción de filtro de ruta
- uses: dorny/paths-filter@v3
  id: changes
  with:
    filters: |
      mobile:
        - 'apps/mobile/**'
        - 'packages/**'
- if: steps.changes.outputs.mobile == 'true'
  run: npm run typecheck -w apps/mobile

• Los cambios en el archivo de bloqueo raíz siempre desencadenan móvil - el gráfico de dependencias puede haber cambiado
• turbo run lint typecheck test --filter=mobile se abanica con caché - GitHub Actions + EAS
• La nocturna aún compila main completo - los filtros de ruta son para velocidad de PR, no cobertura de integración

9. Tren de lanzamiento con compuertas escalonadas

Los equipos avanzados encadenan quality → build → E2E → submit en un archivo de flujo de trabajo.

# .eas/workflows/store-release.yml (esquema)
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_ios:
    needs: [quality]
    type: build
    params: { platform: ios, profile: production }
 
  smoke_ios:
    needs: [build_ios]
    type: maestro
    params:
      build_id: ${{ needs.build_ios.outputs.build_id }}
      flow_path: [".maestro/smoke.yml"]
 
  submit_ios:
    needs: [smoke_ios]
    type: submit
    params:
      platform: ios
      build_id: ${{ needs.build_ios.outputs.build_id }}

• needs encadena el orden - submit no puede ejecutarse si Maestro falló
• Los flujos smoke se mantienen cortos - login, inicio, una pestaña crítica (Maestro E2E)
• Android e iOS pueden paralelizarse después de quality - ver Flujos de trabajo de EAS checklist

10. Coordinación de JS, nativo y backend

Los lanzamientos móviles raramente se envían solos. Documenta dependencias de despliegue en un calendario de lanzamientos.

Tren de lanzamiento semana 12
  Mar - API backend v3 se deploya a staging (pruebas de contrato verdes)
  Mié - eas build production (JS nativo + incrustado)
  Jue - eas update production (hotfix JS si se necesita, mismo runtimeVersion)
  Vie - eas submit después de Maestro + QA manual
  Lun - Lanzamiento por etapas 10% → 50% → 100%

• Calendario de tren de lanzamiento expande el modelo de calendario
• Feature flags desacoplan binario activo de feature visible - Flags de características para lanzamiento seguro
• Pruebas de contrato en comprobaciones de PR detectan desviación de forma de API antes de nocturna

Anti-patrones

Preguntas frecuentes

Relacionado

• Flujos de trabajo de EAS - Checklist YAML para trabajos de compilación, prueba, submit, actualización
• GitHub Actions + EAS - Secretos, caché, disparadores de monorepo
• Compilaciones preview en PRs - Distribución de código QR para QA
• Conceptos básicos de EAS Build - Primera compilación en la nube y eas.json
• Conceptos básicos de actualizaciones OTA - Qué puede cambiar OTA
• Conceptos básicos de pruebas móviles - Pirámide de pruebas para capas de CI
• Mejores prácticas de CI/CD - Resumen de 25 elementos

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