¿Qué es la entrega continua y cómo automatizar despliegues?

La entrega continua (CD) es la práctica de llevar cada cambio de código aprobado hasta producción de forma automática, sin intervención manual.

El problema que CD resuelve

Imagina que el equipo de Liverpool termina una nueva función del carrito de compras. El código pasa las pruebas en CI. Pero para llegar a producción, alguien tiene que conectarse al servidor, copiar archivos y rezar para que nada se rompa. Ese proceso manual tarda horas y genera errores cada semana.

Eso es exactamente lo que la entrega continua elimina. Con CD, el código que pasa todas las pruebas se despliega solo, de forma predecible y trazable. El equipo duerme tranquilo los viernes.

CI vs CD: la diferencia clave

Es fácil confundir integración continua con entrega continua. Aquí está la distinción clara:

CI es la fábrica. CD es el camión de reparto. Sin camión, la mercancía se queda en bodega.

El Framework de Despliegue en Capas

Para automatizar despliegues de forma segura, usa el Framework de Despliegue en Capas. Se divide en tres etapas obligatorias:

Capa 1 — Construcción: el pipeline compila el código y genera un artefacto (un archivo .jar, una imagen Docker, un paquete .zip).

Capa 2 — Validación: el artefacto se despliega en un ambiente de staging. Ahí corren pruebas de integración y pruebas de humo.

Capa 3 — Producción: si staging pasa, el pipeline despliega en producción automáticamente (o con un clic de aprobación, según tu equipo).

Cada capa actúa como filtro. Si algo falla en capa 2, la capa 3 nunca se activa. Así proteges a tus usuarios reales.

Ejemplo completo con GitHub Actions

Supon que trabajas en el backend de pagos de FEMSA. Tu repositorio usa la rama main para producción. Aquí está un pipeline CD real:

name: Deploy Backend FEMSA

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Instalar dependencias
        run: npm install

      - name: Correr pruebas
        run: npm test

      - name: Construir imagen Docker
        run: docker build -t femsa-pagos:latest .

  deploy-staging:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Desplegar en staging
        run: |
          ssh deploy@staging.femsa.com \
            "cd /app && docker pull femsa-pagos:latest && docker-compose up -d"

      - name: Prueba de humo
        run: curl --fail https://staging.femsa.com/health

  deploy-produccion:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment: produccion
    steps:
      - name: Desplegar en producción
        run: |
          ssh deploy@prod.femsa.com \
            "cd /app && docker pull femsa-pagos:latest && docker-compose up -d"

Observa tres cosas importantes de este pipeline:

1. El job deploy-produccion tiene needs: deploy-staging. Si staging falla, producción no se toca.
2. El campo environment: produccion en GitHub Actions puede requerir aprobación manual. Tú decides si quieres ese paso extra.
3. La prueba de humo con curl --fail verifica que el servidor responde antes de continuar. Si devuelve error 500, el pipeline se detiene.

Ambientes: staging no es opcional

Muchos equipos pequeños saltan directo a producción para ahorrar tiempo. Eso es un error costoso.

Un ambiente de staging es una copia exacta de producción con datos de prueba. Su única función es atrapar errores antes de que los vean tus usuarios.

Piénsalo así: Bimbo no lanza una nueva línea de pan directamente en todas sus tiendas. Primero la prueba en una región piloto. Staging es tu región piloto.

Lo mínimo que necesitas en staging:

• La misma versión del sistema operativo que producción.
• Las mismas variables de entorno (sin credenciales reales).
• Una base de datos con datos ficticios pero realistas.

Variables de entorno y secretos

Un error gravísimo en despliegues automatizados es escribir credenciales directamente en el código o en el archivo YAML del pipeline.

Nunca hagas esto:

- name: Conectar a base de datos
  run: mysql -u root -pMiPassword123 -h db.femsa.com

Ese archivo vive en tu repositorio. Cualquier persona con acceso al repo ve esa contraseña.

Haz esto en cambio:

- name: Conectar a base de datos
  run: mysql -u ${{ secrets.DB_USER }} -p${{ secrets.DB_PASSWORD }} -h ${{ secrets.DB_HOST }}

En GitHub, ve a Settings → Secrets and variables → Actions y agrega cada secreto ahí. GitHub los cifra y nunca los muestra en los logs. Así proteges las credenciales de producción de Mercado Libre o cualquier cliente sin importar quién clone el repositorio.

Estrategias de despliegue: elige la correcta

No todos los despliegues son iguales. Hay tres estrategias principales:

Despliegue directo (replace): apaga la versión vieja, levanta la nueva. Simple. Tiene unos segundos de caída. Úsalo en proyectos internos donde la caída no importa.

Blue-Green: tienes dos ambientes idénticos. Uno está activo (blue), el otro en espera (green). Despligas en green, pruebas, y cambias el tráfico. Si algo falla, regresas a blue en segundos. Liverpool usa algo similar para sus temporadas de El Buen Fin.

Canary: envías solo el 5% del tráfico a la nueva versión. Si todo está bien, subes al 25%, luego al 100%. Detecta errores antes de afectar a todos los usuarios. Ideal para cambios de alto riesgo.

Para un equipo que empieza con CD, el despliegue directo está bien. Cuando tu aplicación maneja miles de usuarios concurrentes, considera Blue-Green.

Errores comunes al implementar CD

Error 1: No tener rollback. Si desplegaste código con un bug crítico, necesitas revertir en minutos. Define siempre un proceso de rollback antes de activar CD. El comando mínimo es tener la imagen Docker anterior etiquetada y lista para subir.

Error 2: Pipeline que tarda 40 minutos. Un pipeline lento desmotiva al equipo. Si tus pruebas tardan más de 10 minutos, paraliza los jobs que puedas. GitHub Actions permite correr jobs en paralelo con needs vacío.

Error 3: Desplegar sin prueba de humo. La prueba de humo es el curl --fail que viste arriba. Verifica que la aplicación arrancó correctamente. Sin ella, podrías tener un servidor caído y no enterarte hasta que un usuario llame a soporte.

Error 4: Un solo ambiente. Algunos equipos tienen solo producción. Cualquier cambio va directo ahí. Aunque sea un VPS de $500 al mes, crea un staging mínimo. Vale la inversión.

Error 5: No notificar al equipo. Cuando el pipeline falla, alguien tiene que saberlo de inmediato. Conecta GitHub Actions con Slack o correo. Un despliegue fallido que nadie ve puede dejar producción rota por horas.

Cómo aplicar esto hoy

Si tu equipo ya tiene CI funcionando, sigue estos pasos para agregar CD:

1. Define tus ambientes. Crea un servidor de staging, aunque sea pequeño.
2. Agrega el job de despliegue en tu archivo YAML, después del job de pruebas.
3. Configura tus secretos en GitHub Settings. Nunca en el código.
4. Agrega una prueba de humo con curl --fail apuntando al endpoint /health.
5. Establece un rollback. Documenta en el README cómo revertir al deploy anterior.
6. Notifica al equipo. Agrega un step final que envíe mensaje a Slack si el pipeline falla.

Esto no lo tienes que hacer en un día. Empieza con el paso 1 y el paso 2. El resto lo agregas en la siguiente semana.

El valor real de CD para tu equipo

Un equipo en Guadalajara que trabaja para una startup de logística tardaba tres días en desplegar cada versión. Dos personas dedicaban medio día cada una a coordinar el despliegue manual. Con un pipeline CD básico, ese proceso bajó a 8 minutos automáticos.

Eso son aproximadamente $3,500 en tiempo de ingeniería recuperados cada mes, sin contar los errores humanos evitados.

La entrega continua no es lujo de empresas grandes: es la diferencia entre un equipo que avanza y uno que se atasca en tareas manuales que una máquina puede hacer mejor.