CI/CD e infraestructura como código: 2 semanas

En dos semanas, una reconstrucción de CI/CD e infraestructura como código tiene que dejarte cuatro cosas funcionando de punta a punta. Un control que corre antes de cada push. La infraestructura descrita en código, con el estado cifrado. Un paso de plan que frena los cambios destructivos. Y versiones etiquetadas que se despliegan por digest, la huella única de la imagen. Nuestro paquete de CI/CD e IaC hace eso por USD 4,000.

Prefiero mostrar los comandos, porque “armamos un pipeline” no dice nada. Es la configuración que usamos en nuestros proyectos. Para una plataforma SaaS de analítica de portafolios, el pipeline termina verificando lo mismo: que lo que corre en producción es lo que se publicó.

¿Cómo sabes si tu CI/CD funciona?

No contando herramientas. Las métricas de DORA miden dos cosas: velocidad (tiempo de entrega del cambio, frecuencia de despliegue) e inestabilidad (tasa de fallos, tiempo de recuperación y retrabajo de despliegues). La guía insiste en que velocidad y estabilidad no se contraponen. Si una reconstrucción te hace desplegar más rápido y romper más, no funcionó. Si prefieres que te lo armemos, el paquete de CI/CD e IaC es nuestra versión de alcance fijo.

Antes de empezar, fíjate si hoy las mides de verdad. En The Platform Radar conté el caso de un CTO que estaba seguro de que su equipo medía DORA. Tres minutos de preguntas después, ninguno de los dos estaba tan seguro (la edición está aquí, en inglés). Pasa más de lo que se admite. Cómo sacar cada métrica de datos crudos está en el artículo sobre métricas DORA. Lo grave es descubrirlo después de pasar un trimestre mejorando un número en el que nadie confía.

¿Qué hace el control previo al push?

El lugar más barato para atrapar un build roto es la máquina de quien programa, antes de que algo salga de ahí. El nuestro corre cuatro verificaciones en paralelo antes de cada push: detección de secretos, typecheck, lint y build. Si una falla, el push no se hace.

Una versión mínima para un proyecto Node:

#!/usr/bin/env bash
# scripts/push-gate.sh, se usa así: scripts/push-gate.sh && git push
set -euo pipefail
gitleaks git --redact --log-opts="origin/main..HEAD" &
pnpm typecheck & pnpm lint & pnpm build &
for job in $(jobs -p); do wait "$job"; done

Hacer wait sobre cada proceso propaga su código de salida, así que un solo control en rojo frena todo. En algunos repositorios sumamos reglas de arquitectura y un presupuesto de código muerto. Corre en segundos y en local, con las mismas reglas para todos. Eso último pesa más de lo que parece: una regla que solo se cumple en las máquinas de algunos no es una regla.

¿Cómo se protege el estado de la infraestructura?

El archivo de estado relaciona tu código con los recursos reales y muchas veces guarda valores sensibles. Perderlo duele. Filtrarlo es peor. Usamos OpenTofu, el fork open source de Terraform que comparte su lenguaje HCL, con el estado cifrado. Según su documentación, cifra el estado y los planes en reposo, en local o en un backend, con unas pocas líneas:

terraform {
  encryption {
    key_provider "pbkdf2" "main" {
      passphrase = var.state_passphrase
    }
    method "aes_gcm" "main" {
      keys = key_provider.pbkdf2.main
    }
    state {
      method   = method.aes_gcm.main
      enforced = true
    }
    plan {
      method   = method.aes_gcm.main
      enforced = true
    }
  }
}

La documentación trae dos advertencias que vale la pena repetir. Con el cifrado activo, el estado y los planes quedan irrecuperables sin la clave. Y en un proyecto que ya existe necesitas un método unencrypted temporal para migrar. En producción yo usaría el servicio de gestión de claves de la nube en lugar de una frase de paso, y la clave nunca va en el repositorio.

Si llegaste buscando “Terraform”: casi todo esto sirve igual. El cifrado nativo del estado es lo único propio de OpenTofu.

¿Qué es un freno de cambios destructivos?

Un plan que borra una base de datos se ve igual que uno que agrega una etiqueta, a menos que algo lo lea. El nuestro lo lee. El plan en JSON de OpenTofu lista cada cambio con sus actions, y buscar "delete" ahí detecta tanto borrados como reemplazos:

tofu plan -out=plan.bin
borrados=$(tofu show -json plan.bin \
  | jq '[.resource_changes[] | select(.change.actions | index("delete"))] | length')
if [ "$borrados" -gt 0 ]; then
  echo "El plan borra o reemplaza $borrados recurso(s); requiere aprobación explícita." >&2
  exit 1
fi

Los recursos que guardan datos llevan además prevent_destroy en su ciclo de vida. Eliminarlos exige un commit deliberado, no un accidente.

¿Qué significa publicar por tag y desplegar por digest?

Cada versión es un tag SemVer (el formato v1.4.0: mayor, menor, parche) anotado sobre la rama principal: git tag -a v1.4.0 -m "..." && git push origin v1.4.0. El tag dispara el pipeline, que construye la imagen, corre las migraciones si el repositorio las tiene y despliega.

Cómo se promueve esa versión de un entorno al siguiente, con controles, está en el artículo de Argo CD y Kargo.

El despliegue se hace por el hash de contenido de la imagen, registry/app@sha256:…, nunca por una etiqueta mutable como latest. Un digest nombra exactamente un conjunto de bytes, y por eso puedes demostrar que lo que corre en producción es lo que construiste y probaste:

docker buildx build --push -t "$IMAGE:$TAG" --metadata-file meta.json .
DIGEST=$(jq -r '."containerimage.digest"' meta.json)
gcloud run deploy app --image="$IMAGE@$DIGEST" --region="$REGION"

Al terminar, el pipeline lee el digest que la plataforma está ejecutando de verdad y lo compara con el que construyó. Si no coinciden, la publicación no terminó. Así verificamos cada despliegue a producción de una plataforma de publicidad con IA que construimos para un cliente: 90 versiones en 11 días. Y así se contrastó la primera versión de la plataforma de analítica de portafolios por su nuevo pipeline, con las 12 imágenes en ejecución coincidiendo. Una reversión ensayada en desarrollo tardó 72 segundos hacia atrás y 124 hacia adelante. Fue solo en desarrollo. Todavía no medimos una en producción.

¿Qué pasa durante las dos semanas?

El plan exacto se acuerda el primer día, pero el orden habitual es este.

La primera semana es leer y poner el control. Hacemos el inventario de lo que existe: repositorios, pipelines, cuentas de nube, pasos manuales, secretos. Montamos el control local previo al push y llevamos la infraestructura existente a código, importando lo que ya corre en lugar de recrearlo, con estado remoto cifrado.

La segunda semana es el camino de publicación. Agregamos el freno de plan y prevent_destroy en todo lo que guarda datos, y construimos el pipeline por tags: compilar, migrar, desplegar por digest, verificar. Después pasamos una versión real por ahí y revertimos una.

El criterio de salida es que un cambio real vaya del commit a producción por el camino nuevo mientras tú lo miras. Un pipeline que nunca desplegó nada no está entregado.

¿Tengo que cambiar de herramienta de CI?

Casi nunca. La antigüedad no es la pregunta para ningún servidor de CI, Jenkins incluido. Hazte tres: ¿la definición del pipeline vive en el repositorio?, ¿una ejecución se puede reproducir?, ¿el despliegue está atado a un artefacto inmutable? Si las tres son “sí”, cambiar de herramienta es opcional. Si alguna es “no”, una herramienta nueva no lo arregla.

Rara vez las herramientas son lo difícil. Lo difícil son las decisiones que nadie quiere tomar: quién aprueba un plan destructivo, qué bloquea una versión, cómo funciona una reversión y quién la probó de verdad. Dos semanas alcanzan cuando el alcance es un producto con sus entornos. Si tienes muchos productos con tecnologías distintas, empieza por un Discovery o usa el primer producto como plantilla del resto.

¿Por dónde empiezo?

Describe en una oración cómo sale hoy una versión. Si incluye las palabras “alguien corre”, este paquete es para ti. El alcance completo está en servicios DevOps, y el resto de los paquetes en precios.

Fuentes

• DORA, métricas de desempeño de entrega de software, consultada el 6 de octubre de 2026.
• OpenTofu, State and Plan Encryption, consultada el 6 de octubre de 2026 (última versión publicada ese día: v1.13.1, del 1 de octubre).
• Las dos plataformas: cifras de nuestras propias mediciones, octubre de 2026.