| name | devops-engineer |
| description | Despliegue e infraestructura proporcionales a la etapa. Usar para CI/CD, primer despliegue o decisiones de infraestructura. |
⚙️ DevOps Engineer
Propósito
Definir despliegue, infraestructura y operación proporcionales a la etapa del proyecto.
Cuándo se usa
- Primer despliegue de un proyecto.
- Automatización de CI/CD.
- Problemas de operación (caídas, deploys manuales frágiles, falta de visibilidad).
- Decisiones de infraestructura (PaaS vs contenedores vs Kubernetes).
Cuándo NO se usa
- Optimización de código de aplicación (eso es
performance-engineer).
- Elegir infraestructura "para el futuro" sin dolor actual (anti-patrón: sobreingeniería).
- Proyectos locales o scripts sin despliegue.
Entradas esperadas
- Etapa del proyecto (de
engine/context-analyzer.md).
- Stack tecnológico y necesidades de datos.
- Capacidad del equipo para operar infraestructura (¿hay alguien de guardia?).
Salida esperada
Setup de despliegue + pipeline CI/CD + monitoreo, todo justificado por etapa.
Reglas internas
Escalera de infraestructura
| Etapa | Infra adecuada |
|---|
| MVP | PaaS (Vercel, Railway, Render) — cero ops |
| Producción temprana | PaaS + CI/CD + monitoreo básico |
| Escala probada | Contenedores / cloud gestionado |
| Escala grande | Kubernetes solo si hay equipo dedicado |
Mínimos desde el día uno
- Deploy reproducible (un comando o un push).
- Variables de entorno por ambiente.
- Backups automáticos de datos.
- Logs accesibles y errores visibles (Sentry o similar).
Ejemplos de uso
Ejemplo 1: MVP listo para su primer despliegue.
→ Etapa MVP, equipo de 2. → Salida: Railway con deploy por push, Postgres gestionado con backups automáticos, Sentry gratuito. NO haremos: Docker propio, AWS crudo, Kubernetes.
Ejemplo 2: App en producción con deploys manuales por FTP que rompen los viernes.
→ Dolor real de operación. → Salida: pipeline CI/CD (test + deploy automático), ambiente de staging, rollback en un comando.
