Canales de Liberación y Ramas

Promoción staging → producción con EAS Update - un manual de recetas para canales, ramas, y el flujo de promoción lineal que mantiene la QA de vista previa alineada con el comportamiento de producción.

Receta

Tarjeta de referencia rápida - lista para copiar y pegar.

// eas.json - un canal por perfil de construcción
{
  "build": {
    "preview": { "distribution": "internal", "channel": "preview" },
    "production": { "channel": "production" }
  }
}

# Publicar en rama preview (prueba)
eas update --branch preview --channel preview --environment preview \
  --message "feat: arreglo de validación de checkout"
 
# Después de la aprobación de QA - publicar el mismo commit en canal de producción
eas update --branch production --channel production --environment production \
  --message "promote: arreglo de validación de checkout"

# Inspeccionar qué sirve cada canal
eas channel:view production
eas update:list --branch production --limit 5

Cuándo usarlo:

• Configurar tu primer flujo development → preview → production.
• Promocionar un bundle de vista previa probado a usuarios de producción.
• Asignar ramas Git a ramas de EAS Update para equipos basados en trunk.
• Auditar qué ID de bundle sirve actualmente el canal de producción.

Cuándo evitarlo:

• Canales por ingeniero (jane-dev) - usa construcciones de vista previa + actualizaciones de rama en su lugar.
• Publicación directa en producción desde una rama de feature sin prueba en vista previa en rutas de ingresos.
• Compartir un canal de producción entre dos IDs de bundle - las necesidades de etiqueta blanca requieren canales separados.

Ejemplo Funcional

Promoción staging → preview → production de extremo a extremo con tablas de canal/rama y puerta de CI.

Paso 1 - Documentar el mapa de canales

<!-- docs/release-channels.md -->
| Canal        | Perfil binario | Audiencia       | Quién puede publicar      |
|--------------|----------------|-----------------|--------------------------|
| development  | development    | Ingenieros      | Cualquier dev (local)     |
| preview      | preview        | QA + stakeholders | Tech lead de turno      |
| staging      | preview*       | Prueba pre-prod | Gerente de liberación     |
| production   | production     | Usuarios de tienda | Solo CI tag              |
 
* staging usa binary de perfil preview con anulación de encabezado `expo-channel-name: staging` si es necesario

Paso 2 - Conectar ramas a canales

# Una sola vez: asegurar que los canales apunten a las ramas deseadas
eas channel:create preview
eas channel:create production
eas channel:edit preview --branch preview
eas channel:edit production --branch production

Paso 3 - Trabajo de feature en preview

git checkout -b fix/checkout-validation
# ... cambios de JS solo (OTA-safe) ...
 
eas update --branch preview --channel preview --environment preview \
  --message "fix: expresión regular de validación de tarjeta"

Paso 4 - QA en binario de preview

# QA instala artefacto de eas build --profile preview
# Humo de Maestro + ruta de pago manual en dispositivo físico
eas update:list --branch preview --limit 3

Paso 5 - Promocionar a producción (CI preferido)

# .github/workflows/eas-update-production.yml (extracto)
name: Promote OTA to production
on:
  workflow_dispatch:
    inputs:
      message:
        required: true
jobs:
  update:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: expo/expo-github-action@v8
        with:
          eas-version: latest
          token: ${{ secrets.EXPO_TOKEN }}
      - run: eas update --branch production --channel production \
               --environment production \
               --message "${{ github.event.inputs.message }}"

Lo que esto demuestra:

• Las ramas almacenan el historial de actualizaciones; los canales son el puntero que las aplicaciones consultan en tiempo de ejecución
• La prueba de vista previa ocurre en el mismo canal que los binarios de QA incorporan a través de requestHeaders
• La promoción de producción es una segunda publicación deliberada - no una edición de canal accidental
• La publicación de producción solo por CI deja un rastro de auditoría (eas update:list, registros de GitHub Actions)

Análisis Profundo

Canales vs Ramas

eas update --branch feature-x     →  escribe bundle en rama "feature-x"
eas channel:edit preview --branch feature-x   →  canal preview ahora sirve feature-x
La app verifica el canal "preview"      →  recibe la cabeza de rama feature-x

• eas update --channel production publica en la rama actualmente vinculada a production
• Prefiere explícitamente --branch al promocionar para que el historial permanezca rastreable
• eas channel:view <name> muestra el mapeo de rama y el ID de actualización actual

Flujo de Promoción Lineal

development  →  preview (QA)  →  staging (prueba opcional)  →  production
     ↑              ↑                      ↑                        ↑
  ingeniero    construcción interna    prueba 24-48h          solo CI tag

• development: iteración rápida; puede romperse; no para stakeholders
• preview: binario similar a liberación; requiere humo de Maestro
• staging (opcional): prueba más larga para auth/pago; misma clase de binario que preview
• production: usuarios de tienda; regla de dos personas o solo CI

Asignar Ramas Git a Ramas de EAS

# Basado en trunk: publicar desde main a rama preview
git checkout main
eas update --branch preview --channel preview --environment preview
 
# GitFlow: publicar desde release/x.y a rama staging
git checkout release/2.4
eas update --branch staging --channel staging --environment staging

• Las ramas de EAS no están automáticamente vinculadas a ramas Git - tú aplicas el mapeo en CI
• Documenta qué rama Git puede publicar en qué canal de EAS en CONTRIBUTING.md
• Rechaza publicación directa de production desde ramas de feature sin fusionar

Patrón de Promoción de Republicación

Cuando preview y production deben ejecutar el mismo artefacto de bundle:

# Opción A - cherry-pick commit y publicar en rama de producción
git checkout main
git cherry-pick <preview-commit-sha>
eas update --branch production --channel production --environment production \
  --message "promote: <ticket-id>"
 
# Opción B - redirección de canal (avanzado; usa con cuidado)
eas channel:edit production --branch preview
# Sigue inmediatamente con división de rama si preview continúa divergiendo

• La opción A preserva el historial Git claro por canal
• La opción B es más rápida pero difumina la semántica de rama - documenta en runbook
• Siempre registra la ventana de prueba de preview y el ID de bundle en el ticket de liberación

Errores Comunes

• Encabezado de canal ≠ canal de eas update - El binario construido con encabezado preview nunca ve actualizaciones de production. Solución: Reconstruye o coincide el canal de publicación con el encabezado incorporado.
• Omitir preview para "pequeño" arreglo de pago - Los incidentes cuestan más que el tiempo de prueba. Solución: Mínimo 24h de preview en rutas de ingresos según Release & OTA Rules.
• .env local en publicación de producción - Host de API incorrecto en bundle de OTA. Solución: eas update --environment production siempre.
• Dos apps, un canal - La app de consumidor recibe JS de app de negocio. Solución: Separar projectId, canal e ID de bundle por variante.
• Viernes producción OTA sin soporte durante el fin de semana - Rollback a las 6 p.m. sin cobertura. Solución: Política en reglas de liberación.

Alternativas

Preguntas Frecuentes

eas channel:view production
eas update:view <update-id>

Relacionado

• OTA Updates Basics - Límites de OTA vs tienda
• expo-updates Configuration - Cableado de requestHeaders
• Staged Rollouts - Rollouts de porcentaje en canales
• Rollback Runbook - Republicación de canal en minutos
• EAS Build Basics - Perfiles que incorporan canales
• Release & OTA Rules - Lista de verificación de promoción Tier 2

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