Pipelines multi-stage: Build → Docker → Deploy automatizado en 10 minutos
Un pipeline CI/CD bien armado corta errores humanos, acelera lanzamientos y te deja dormir tranquilo. Te explico la arquitectura en 3 etapas que usamos.
Si tu deploy todavía consiste en conectarte al servidor y correr comandos a mano, estás perdiendo tiempo y metiendo errores. Un pipeline multi-stage automatiza el viaje del código: desde que haces git push hasta que el cambio está vivo en producción, sin que toques el servidor.
¿Qué es un pipeline multi-stage?
Un pipeline es una receta automática que se dispara cuando haces un cambio en tu repositorio. "Multi-stage" significa que esa receta está dividida en fases independientes, cada una con su trabajo específico.
La arquitectura que usamos tiene 3 etapas:
Git push → Stage 1: Build → Stage 2: Docker → Stage 3: Deploy → Producción
Si una etapa falla, las siguientes no corren. Código roto nunca llega a producción.
Stage 1: Build
Aquí se compila y prueba el código. Acciones típicas:
- Descarga del repositorio.
- Instalación de Node.js (o el runtime que uses).
- Cache de dependencias (para no reinstalar todo cada vez).
npm installynpm run build.- Ejecución de tests automatizados.
Condición: corre en cada push a main y en cada pull request.
Si los tests fallan o el build rompe, el pipeline se detiene. El desarrollador recibe un mensaje y nada cambia en producción.
Stage 2: Docker
Si Stage 1 pasa, creamos una imagen Docker lista para deployar:
- Login al registro de imágenes (AWS ECR, Docker Hub, GitLab Registry, etc.).
- Build de la imagen usando el
Dockerfiledel proyecto. - Dos tags: uno con el número de build (
20260415.1) y uno con el SHA corto del commit (a1b2c3d). - Push de la imagen al registro.
- Generación de un archivo
deploy.jsoncon la información de esta versión.
¿Por qué dos tags? El tag con SHA es único por commit (nunca se reusa). El tag con número de build es secuencial (útil para humanos). Esto permite hacer rollback específico si algo sale mal.
Condición: solo si Stage 1 terminó bien.
Stage 3: Deploy
Con la imagen ya en el registro, actualizamos el servidor de producción:
- Descarga del
deploy.jsonde Stage 2. - Conexión al servidor vía el mecanismo del proveedor cloud (sin SSH abierto, ver post relacionado).
docker pullde la nueva imagen.docker-compose up -dpara levantar la nueva versión.- Healthcheck automático: el pipeline hace una petición a
/api/healthy espera respuesta 200 durante 30 segundos. - Si el healthcheck falla, el pipeline marca el deploy como fallido (y puedes configurar rollback automático).
Condición: solo si Stage 2 terminó bien Y el branch es main.
El truco que casi nadie aplica: branch protection
Un pipeline solo protege si la única forma de cambiar código en main es a través del pipeline. Eso se logra con reglas de branch protection:
- Nadie puede hacer
pushdirecto amain. Solo merges desde pull request. - Un PR no se puede mergear si el pipeline falla.
- Un PR necesita mínimo 1 aprobación de otro desarrollador.
mainno se puede borrar ni forzar push.
Sin estas reglas, cualquiera puede saltarse el pipeline y el automatizado no sirve de nada.
Ventajas reales que vas a sentir
1. Deploys más rápidos De 30 minutos manuales a 5–10 minutos automáticos. Multiplica por la cantidad de deploys al mes.
2. Cero errores por "me faltó un paso"
El pipeline corre los mismos comandos en el mismo orden siempre. Olvidarte de un npm install ya no existe.
3. Rollback instantáneo ¿Algo roto en producción? Sacas el SHA del deploy anterior y le dices al servidor "usa esta imagen". 60 segundos de rollback.
4. Historial auditable Sabes exactamente qué código, qué commit, qué versión, cuándo, y quién ejecutó cada deploy. Indispensable para certificaciones.
5. Confianza para desplegar seguido Cuando deployar es caro y riesgoso, acumulas cambios y lanzas una vez al mes (= más riesgo). Cuando es barato y seguro, lanzas cambios chicos todos los días.
¿Qué herramienta uso?
Las tres grandes opciones hoy:
- GitHub Actions — si tu código vive en GitHub, es lo más directo.
- GitLab CI/CD — si usas GitLab, ya viene incluido.
- Azure DevOps Pipelines — potente, buena integración con AWS si usas autenticación por OIDC.
Para este tipo de arquitectura las tres sirven. La diferencia real está en ecosistema y precio, no en capacidad técnica.
¿Cuándo lo necesitas?
- Tus deploys toman más de 15 minutos y son manuales.
- Ya tuviste un downtime porque "olvidé un paso en el deploy".
- Más de 1 persona toca el código y no hay un proceso común.
- Cumplimiento (SOC2, ISO) exige trazabilidad de cambios.
- Quieres hacer varios deploys al día sin miedo.
En ServerStack Solutions
Cada proyecto que entregamos viene con su pipeline multi-stage desde el día 1: build, Docker, ECR, deploy automatizado a servidor cloud, healthcheck y logs centralizados. Tú solo haces git push.
Contáctanos si quieres montar un pipeline en tu infraestructura actual.
Relacionado: Azure Pipelines CI/CD automatizado y Docker + ECR: gestión segura de contenedores.
Preguntas frecuentes
¿Qué es un pipeline multi-stage?
Un pipeline dividido en etapas (stages) con propósitos distintos: build, test, deploy a staging, deploy a producción. Cada stage puede correr en paralelo o secuencial, tiene sus propias variables/secrets, y puede requerir aprobaciones manuales entre uno y otro. Multi-stage vs un pipeline monolítico da mejor aislamiento y control.
¿Cuánto tarda configurar un pipeline así desde cero?
Un equipo con experiencia previa en CI/CD: 2-4 días para tener el pipeline funcionando con build, test y deploy a un ambiente. Sin experiencia previa: 2-3 semanas con curva de aprendizaje incluida. En ServerStack lo entregamos configurado en 3-5 días como parte de nuestros proyectos.
¿Necesito Docker para este tipo de pipeline?
No estrictamente, pero ayuda mucho. Sin Docker puedes desplegar código fuente compilado directo al servidor, pero tienes que lidiar con dependencias del sistema que difieren entre staging y prod. Con Docker, la imagen es idéntica — si pasó los tests en staging, pasa en producción. Ver nuestro post sobre Docker + ECR.