Pipelines de CI/CD
Nivel intermedio — configurar pipelines de integración y despliegue continuo que automaticen validación y deployment.
El problema
Situación típica: el equipo hace merge a main. Nadie corrió los tests porque "tomaban mucho tiempo". El deploy a producción falla por una dependencia faltante que nadie notó en local. Revertir toma una hora porque nadie documentó el proceso de rollback. // el código que "funcionaba en mi máquina" rompe producción un viernes a las 6pm
Anatomía de un pipeline
Un push dispara CI (Continuous Integration); un merge o tag dispara CD (Continuous Deployment):
Regla del pipeline: si falla cualquier paso, el pipeline se detiene. No hay "saltarse" el lint porque hay prisa — esa es exactamente la disciplina que CI/CD existe para automatizar.
Las 7 etapas
| Etapa | Trigger | Qué hace | Si falla |
|---|---|---|---|
| Lint | Push | Valida estilo de código | Bloquea merge |
| Unit Test | Push | Tests rápidos de lógica | Bloquea merge |
| Integration Test | Push | Tests con base de datos | Bloquea merge |
| Build | Push | Construye artefactos | Bloquea merge |
| Deploy Staging | Merge a main | Despliega a staging | Alerta al equipo |
| E2E Test | Post-staging | Valida en ambiente real | Bloquea prod |
| Deploy Prod | Tag/Manual | Despliega a producción | Rollback automático |
CI/CD automatiza la ejecución de la validación, no la validación en sí. Si la suite de tests tiene huecos (recuerda la Lección 5.3: la distribución en la pirámide importa más que el número), el pipeline verde solo te da una falsa sensación de seguridad más rápido. Automatizar un mal proceso lo hace fallar más rápido, no lo convierte en uno bueno.
Practica: GitHub Actions para el skeleton
Configura un workflow de GitHub Actions (.github/workflows/ci.yml) para el Walking Skeleton con las 7 etapas: lint y tests en cada push, build, deploy automático a staging al hacer merge a main, validación E2E post-staging, y deploy a producción disparado por un tag de versión.