Recorré las etapas de un pipeline de CI/CD real, desde el commit hasta producción

#Un pipeline es una serie de apuestas cada vez más costosas sobre que tu cambio es seguro

"Pipeline de CI/CD" se dice como si fuera una sola palabra, pero en realidad responde dos preguntas distintas que suelen correr una después de la otra. La Integración Continua pregunta "¿este cambio está bien, aislado, ahora mismo?" — compilarlo, testearlo, escanearlo, lo más rápido posible, en cada commit. La Entrega Continua (Continuous Delivery) y su hermana más agresiva, el Despliegue Continuo (Continuous Deployment), preguntan "¿el sistema está lo suficientemente bien como para entregarle este cambio a un usuario real?" — desplegarlo en un entorno real, verificarlo en condiciones reales, y solo entonces dejar que llegue al tráfico de producción. Entrega significa que cada cambio está siempre listo para lanzarse, a un clic de distancia; despliegue significa que se lanza automáticamente en el momento en que pasa. La mayoría de los equipos serios corren entrega con un gate manual antes del paso final a producción, no despliegue completo, porque un punto de decisión humano antes del tráfico de clientes es un control de riesgo deliberado, no una automatización faltante.

#Las etapas, en el orden que realmente tiene sentido

El orden es deliberado, no arbitrario: siempre corrés primero los chequeos más baratos y más rápidos. Un linter y los tests unitarios terminan en segundos y atrapan la mayoría de los errores triviales; no tiene sentido gastar cinco minutos construyendo una imagen de contenedor solo para descubrir que el código ni siquiera compila. El escaneo de seguridad va antes del empaquetado porque un CVE crítico en una imagen base o una dependencia filtrada debería frenar el pipeline antes de gastar tiempo construyendo y subiendo un artefacto que vas a tener que descartar. Desplegar a staging ocurre solo después de construir el artefacto una única vez — desplegás la misma imagen exacta en todos lados, nunca la reconstruís por ambiente, porque reconstruir es justamente cómo se cuelan los bugs de "funcionó en staging, se rompió en prod", cuando una dependencia resuelve distinto en una segunda build.

#Un pipeline real, en GitHub Actions

name: CI/CD

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-go@v5
        with:
          go-version: "1.22"

      - name: Instalar dependencias
        run: go mod download

      - name: Lint
        run: go vet ./...

      - name: Tests unitarios
        run: go test -race -coverprofile=coverage.out ./...

      - name: Escaneo de dependencias y contenedor
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: fs
          exit-code: 1
          severity: CRITICAL,HIGH

  build-and-push-image:
    needs: build-and-test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Iniciar sesión en el registry
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Construir y subir
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ghcr.io/acme/api:${{ github.sha }}

  deploy-staging:
    needs: build-and-push-image
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - name: Desplegar a staging
        run: ./scripts/deploy.sh staging ${{ github.sha }}

      - name: Smoke test de staging
        run: ./scripts/smoke-test.sh https://staging.acme.internal

  deploy-production:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://api.acme.com
    steps:
      - name: Desplegar canary (10% del tráfico)
        run: ./scripts/deploy.sh production ${{ github.sha }} --strategy=canary

      - name: Verificar salud del canary
        run: ./scripts/verify-canary.sh

      - name: Promover a rollout completo
        run: ./scripts/deploy.sh production ${{ github.sha }} --strategy=promote

El bloque environment: production hace trabajo real, no es solo documentación — GitHub permite asociarle revisores obligatorios a un environment, así que el job se pausa antes de correr hasta que alguien lo aprueba. Ese es el gate manual del diagrama, expresado como configuración en vez de una herramienta de aprobación separada. Notá también que el mismo github.sha atraviesa todos los jobs: staging y producción corren la imagen idéntica, construida una única vez.

#Por qué el paso de deploy nunca es realmente "un solo comando"

Un job de despliegue a producción que simplemente cambia todas las instancias a la vez a la nueva versión es una apuesta sin seguro. El paso de canary de arriba despliega la nueva versión a una porción pequeña de tráfico real, observa métricas reales (tasa de error, latencia) contra una línea base, y solo entonces promueve al resto — la misma idea que un despliegue blue-green o rolling, todos los cuales existen para responder automáticamente, en vez de manualmente, una pregunta: "¿esto realmente funcionó, antes de que todos queden expuestos?". Si el chequeo de salud falla, el camino de rollback tiene que estar al menos tan automatizado como el de rollout; un rollback que depende de que alguien recuerde el tag de la imagen anterior a las 2 de la madrugada no es una estrategia de rollback.

🧠 Check your understanding
0/3 · 0/3 answered
1. ¿Por qué los escaneos de seguridad y dependencias suelen correr antes de construir y subir la imagen del contenedor, y no después?
Los escáneres no pueden inspeccionar imágenes de contenedorPorque los registries no permiten escanearPara que una vulnerabilidad bloqueante se detecte antes de gastar tiempo construyendo y subiendo un artefacto que habrá que descartarNo afecta el orden, es arbitrario
2. ¿Cuál es la diferencia clave entre Continuous Delivery y Continuous Deployment?
Deployment no usa pipelinesDelivery solo aplica a apps móvilesDelivery significa que cada cambio siempre está en un estado liberable, típicamente con un gate manual antes de producción; Deployment significa que los cambios que pasan van a producción automáticamente sin paso manualNo hay diferencia, son la misma práctica
3. Un despliegue canary envía la nueva versión al 10% del tráfico de producción y lo monitorea antes de continuar. ¿Contra qué protege principalmente esto?
Un bug o regresión que solo aparece bajo tráfico real de producción, alcanzando a todos los usuarios antes de que alguien lo notePerder código fuente durante un mergeEl costo de correr un servidor de CITiempos de build lentos