C4 devops

C4 — Reto Tecnico: DevOps e Infraestructura Cloud#

Cargo: DevOps e Infraestructura Cloud Tipo de reto: Desarrollo de producto Stack: Docker, CI/CD, GCP/AWS, Terraform, monitoreo, seguridad Producto: DeployOps — Tomar una app existente y hacerla production-ready Metodologia de evaluacion: Ver 00-metodologia-evaluacion.md

1. Vision del Producto#

Producto: DeployOps — No construyes una app desde cero. Recibes una aplicacion Node.js + PostgreSQL ya funcional (repo proporcionado) y tu trabajo es: dockerizarla, configurar CI/CD, desplegarla, monitorearla, asegurarla, y hacerla resiliente.

Problema que resuelve: Los equipos de desarrollo entregan codigo que "funciona en mi maquina". Tu trabajo es que funcione en produccion, de forma segura, automatizada y observable.

Contexto: Se te entrega el repo taskflow-app — una app Kanban funcional con NestJS + Next.js + Prisma + PostgreSQL. El codigo esta listo pero no tiene: Dockerfile, CI/CD, monitoring, secrets management, ni deploy.

1.1 Repo Proporcionado#

El candidato recibe acceso a un repositorio privado critertec/taskflow-devops-challenge que contiene:

taskflow-app/
  ├── backend/          (NestJS + Prisma + PostgreSQL)
  ├── frontend/         (Next.js + TailwindCSS)
  ├── prisma/           (schema + migrations)
  ├── .env.example      (variables necesarias)
  ├── package.json
  └── README.md         (instrucciones de setup local)

La app funciona localmente con npm run dev. Tu trabajo es llevarla a produccion.

2. Historias de Usuario — Backlog Priorizado#

H01 — Dockerizacion#

Prioridad: Critica | Nivel minimo: N1 | Estimacion: 3 pts

Como DevOps, quiero contenerizar la app para que funcione igual en cualquier entorno.

Criterios de aceptacion:

• AC-01: Dockerfile para backend: multi-stage build (builder + runner). Imagen final < 200MB
• AC-02: Dockerfile para frontend: multi-stage build. Imagen final < 150MB
• AC-03: docker-compose.yml que levanta: backend, frontend, PostgreSQL, y opcionalmente Redis
• AC-04: docker compose up levanta todo y la app es accesible en http://localhost:3000
• AC-05: Las migraciones de Prisma corren automaticamente al iniciar el backend (entrypoint script)
• AC-06: Healthcheck en docker-compose para cada servicio
• AC-07: .dockerignore correcto: no copia node_modules, .env, .git, tests al build context

Definition of Done: git clone + docker compose up = app funcionando. Imagenes verificadas con docker images (< 200MB y < 150MB).

H02 — Gestion de secretos#

Prioridad: Critica | Nivel minimo: N1 | Estimacion: 2 pts

Como DevOps, quiero que los secretos esten gestionados correctamente y nunca en el repo.

Criterios de aceptacion:

• AC-01: .env.example en el repo con todas las variables necesarias y valores de ejemplo (no reales)
• AC-02: .env en .gitignore. Verificar que no hay secrets en el historial de git (git log --all -p | grep -i secret)
• AC-03: Docker compose usa env_file: .env o variables inyectadas. No hardcodea valores
• AC-04: Documentar en README todas las variables, para que sirven, y de donde obtener cada una
• AC-05: Script scripts/check-secrets.sh que escanea el repo por patrones de secrets (API keys, passwords, tokens) y reporta si encuentra alguno

Definition of Done: Cero secrets en el repo. Script de verificacion pasa limpio.

H03 — CI/CD Pipeline basico#

Prioridad: Critica | Nivel minimo: N1 | Estimacion: 5 pts

Como DevOps, quiero que cada push a main despliegue automaticamente si los tests pasan.

Criterios de aceptacion:

• AC-01: Pipeline en GitHub Actions (o Cloud Build) con stages: install → lint → test → build → deploy
• AC-02: El pipeline corre en cada push a main y en cada Pull Request
• AC-03: Si lint falla, el pipeline se detiene y reporta el error
• AC-04: Si tests fallan, el pipeline se detiene. No se despliega
• AC-05: Si build de Docker falla, pipeline se detiene
• AC-06: Variables de entorno gestionadas con GitHub Secrets (o equivalente del CI)
• AC-07: Badge de estado del pipeline en el README

Definition of Done: Push a main → pipeline verde → app actualizada en URL de produccion.

H04 — Deploy a produccion#

Prioridad: Critica | Nivel minimo: N1 | Estimacion: 3 pts

Como DevOps, quiero la app corriendo en una URL publica accesible.

Criterios de aceptacion:

• AC-01: App desplegada y accesible en URL publica (HTTPS)
• AC-02: Base de datos PostgreSQL desplegada (Railway, Supabase, Cloud SQL, o similar)
• AC-03: Frontend y backend se comunican correctamente en produccion (CORS, env vars)
• AC-04: Deploy automatizado via CI/CD (no manual)
• AC-05: README documenta: URL de produccion, como hacer deploy manual (fallback), como verificar que funciona

Definition of Done: URL funciona. Puedo registrarme, crear tablero, y mover tarjetas.

H05 — Estrategia de branching y environments#

Prioridad: Alta | Nivel minimo: N2 | Estimacion: 3 pts

Como DevOps, quiero ambientes separados para desarrollo y produccion.

Criterios de aceptacion:

• AC-01: Al menos 2 ambientes: staging (branch develop) y produccion (branch main)
• AC-02: Push a develop despliega a staging automaticamente (URL diferente)
• AC-03: Push a main despliega a produccion
• AC-04: Variables de entorno diferentes por ambiente (DB, API URL, feature flags)
• AC-05: Documentar la estrategia de branching en el README o en un ADR

Definition of Done: Dos URLs funcionando: staging y produccion. Cada una con su propia DB.

H06 — Healthcheck y endpoint de salud#

Prioridad: Alta | Nivel minimo: N2 | Estimacion: 2 pts

Como operador, quiero verificar que la app esta viva y sana.

Criterios de aceptacion:

• AC-01: Endpoint GET /health en el backend que retorna:

  json
  {
    "status": "ok",
    "version": "1.2.3",
    "uptime": 3600,
    "database": "connected",
    "timestamp": "2026-03-07T12:00:00Z"
  }

• AC-02: Si la DB no esta conectada, retorna status 503 con "database": "disconnected"
• AC-03: Docker healthcheck usa este endpoint
• AC-04: El CI/CD verifica el healthcheck despues del deploy (smoke test)

Definition of Done: Endpoint accesible. Docker healthcheck funcionando. CI verifica post-deploy.

H07 — Logging estructurado#

Prioridad: Alta | Nivel minimo: N2 | Estimacion: 3 pts

Como operador, quiero logs utiles para diagnosticar problemas.

Criterios de aceptacion:

• AC-01: Logging con pino o winston. Formato JSON en produccion, formato legible en desarrollo
• AC-02: Cada log incluye: timestamp, level, message, requestId (correlacion), service name
• AC-03: Logs de requests HTTP: method, path, status, duration, IP
• AC-04: Logs de errores incluyen stack trace completo
• AC-05: Nivel de log configurable via env var (LOG_LEVEL=info|debug|warn|error)
• AC-06: No loggear datos sensibles: passwords, tokens, PII

Definition of Done: Logs visibles en docker compose logs. Formato JSON. RequestId correlaciona request con su respuesta.

H08 — Reverse proxy y HTTPS#

Prioridad: Alta | Nivel minimo: N2 | Estimacion: 3 pts

Como DevOps, quiero la app detras de un proxy con HTTPS.

Criterios de aceptacion:

• AC-01: Nginx o Caddy como reverse proxy delante del backend y frontend
• AC-02: HTTPS con certificado valido (Let's Encrypt via Caddy, o Cloudflare, o cert del provider)
• AC-03: HTTP redirige a HTTPS automaticamente
• AC-04: Headers de seguridad: HSTS, X-Frame-Options, X-Content-Type-Options, CSP basico
• AC-05: Rate limiting a nivel de proxy: 100 req/min por IP en endpoints de auth

Si usa plataforma manejada (Vercel, Railway): documentar que el HTTPS y headers los gestiona la plataforma. Demostrar configuracion.

Definition of Done: curl -I https://app.example.com muestra headers de seguridad. HTTP redirige a HTTPS.

H09 — Monitoring y alertas#

Prioridad: Alta | Nivel minimo: N3 | Estimacion: 5 pts

Como operador, quiero metricas y alertas para detectar problemas antes de que afecten a los usuarios.

Criterios de aceptacion:

• AC-01: Metricas de la app expuestas: requests/segundo, latencia p50/p95/p99, tasa de errores, conexiones DB activas
• AC-02: Metricas del sistema: CPU, memoria, disco (del container)
• AC-03: Dashboard de metricas accesible (Grafana, Cloud Monitoring, Uptime Kuma, o pagina custom)
• AC-04: Alerta configurada: si healthcheck falla 3 veces consecutivas, notificar (email, Slack webhook, o log)
• AC-05: Alerta de latencia: si p95 > 2 segundos durante 5 minutos, notificar
• AC-06: Uptime check externo (UptimeRobot, Better Uptime, o custom cron)

Definition of Done: Dashboard accesible con metricas reales. Al menos 1 alerta configurada y demostrada.

H10 — Backup y disaster recovery#

Prioridad: Alta | Nivel minimo: N3 | Estimacion: 3 pts

Como operador, quiero poder recuperar datos si algo sale mal.

Criterios de aceptacion:

• AC-01: Script de backup de PostgreSQL: scripts/backup-db.sh que genera dump comprimido con fecha
• AC-02: Backup automatico: cron job que ejecuta el backup cada 24h
• AC-03: Script de restore: scripts/restore-db.sh que restaura desde un dump
• AC-04: Documentar procedimiento de disaster recovery: cuanto tiempo toma? cuantos datos se pierden (RPO)?
• AC-05: Backup almacenado en ubicacion diferente al servidor de la app (GCS bucket, S3, otro disco)
• AC-06: Test de restore documentado: "restaure el backup del dia X y verifique que la app funciona"

Definition of Done: Backup generado. Restore ejecutado y verificado. Documentacion del procedimiento.

H11 — Seguridad y hardening#

Prioridad: Media | Nivel minimo: N3 | Estimacion: 3 pts

Como DevOps, quiero la app asegurada contra ataques comunes.

Criterios de aceptacion:

• AC-01: Escaneo de vulnerabilidades de Docker images: docker scout o trivy integrado en CI
• AC-02: Dependencias auditadas: npm audit en CI. Pipeline falla si hay vulnerabilidades criticas
• AC-03: Container corre como non-root user
• AC-04: Network: solo los puertos necesarios expuestos. DB no accesible desde internet
• AC-05: CORS estricto: solo origenes permitidos, no *
• AC-06: Firewall rules documentadas: que puertos, que IPs, que protocolos

Definition of Done: Trivy report limpio (sin criticos). Container non-root. DB no expuesta.

H12 — Testing de infraestructura#

Prioridad: Alta | Nivel minimo: N3 | Estimacion: 3 pts

Como DevOps, quiero tests que verifiquen la infraestructura.

Criterios de aceptacion:

• AC-01: Test que verifica que docker compose up levanta todos los servicios y pasan healthcheck
• AC-02: Test de smoke post-deploy: endpoint /health responde 200, frontend carga, puede registrar usuario
• AC-03: Test de rollback: poder volver a la version anterior en menos de 5 minutos
• AC-04: Load test basico: 100 requests concurrentes a endpoints principales, ninguno falla con 500, latencia p95 < 2s
• AC-05: npm test o script de test corre sin configuracion adicional

Herramientas sugeridas: k6, Artillery, autocannon, o custom script con curl/ab.

Definition of Done: Tests de infra corren en CI. Load test report generado.

H13 — Infrastructure as Code (solo N4)#

Prioridad: Media | Nivel minimo: N4 | Estimacion: 5 pts

Como DevOps senior, quiero la infraestructura definida como codigo para reproducir el ambiente.

Criterios de aceptacion:

• AC-01: Terraform, Pulumi, o CDK definiendo: compute (Cloud Run, ECS, VM), DB (Cloud SQL, RDS), networking
• AC-02: Estado remoto (Terraform state en GCS/S3, no local)
• AC-03: Ambientes parametrizados: terraform apply -var environment=staging vs production
• AC-04: Plan documentado: terraform plan muestra los recursos antes de aplicar
• AC-05: Destruccion segura: script que elimina staging pero nunca produccion (proteccion)

Definition of Done: terraform plan muestra recursos correctos. terraform apply despliega. Documentado.

H14 — Observabilidad avanzada (solo N4)#

Prioridad: Media | Nivel minimo: N4 | Estimacion: 3 pts

Como operador senior, quiero trazabilidad completa de cada request.

Criterios de aceptacion:

• AC-01: Distributed tracing: cada request tiene un trace ID que se propaga entre frontend, backend, y DB
• AC-02: APM basico: mapa de servicios, latencia por servicio, errores por servicio
• AC-03: Log aggregation: todos los logs centralizados (Loki, CloudWatch, o similar)
• AC-04: Runbook documentado: "si la app esta lenta, estos son los 5 pasos de diagnostico"

Definition of Done: Trace ID visible en logs. Dashboard de APM accesible.

H15 — Documentacion de arquitectura (solo N4)#

Prioridad: Media | Nivel minimo: N4 | Estimacion: 2 pts

Criterios de aceptacion:

• AC-01: Diagrama de infraestructura: que servicios, como se conectan, que provider, que region
• AC-02: ADRs: por que este provider? por que esta estrategia de deploy? por que esta herramienta de monitoring?
• AC-03: README completo: como desplegar desde cero, como verificar, como hacer rollback
• AC-04: Runbook de operaciones: procedimientos para los 5 incidentes mas comunes

Definition of Done: Un DevOps nuevo puede desplegar la app completa leyendo solo el README.

3. Sprint Planning — Que completar segun tu nivel#

4. Timebox del Sprint#

5. Entregables#

6. Stack sugerido (no obligatorio)#

Reto especifico para C4 — DevOps. Para la rubrica general y metodologia, ver 00-metodologia-evaluacion.md