1 · Elección de estrategia de despliegue
Rolling
Actualización instancia a instancia
Pod 1: v1 → v2
Pod 2: v1 (activo)
Pod 3: v1 (activo)
──────────────────
Pod 1: v2 ✓
Pod 2: v1 → v2
Pod 3: v1 (activo)
Pod 2: v1 (activo)
Pod 3: v1 (activo)
──────────────────
Pod 1: v2 ✓
Pod 2: v1 → v2
Pod 3: v1 (activo)
✓ Zero downtime garantizado
✓ Sin infra extra
✗ 2 versiones simultáneas
✗ Rollback más lento
Blue-Green
Dos entornos espejo, switch atómico
Blue (v1) ← tráfico activo
Green (v2) idle/nuevo
──────────────────
tras verificar:
Blue (v1) idle/standby
Green (v2) ← tráfico activo
Green (v2) idle/nuevo
──────────────────
tras verificar:
Blue (v1) idle/standby
Green (v2) ← tráfico activo
✓ Rollback instantáneo
✓ Cutover limpio
✗ 2x infraestructura
✗ Descartada por coste
Canary
Tráfico gradual al nuevo módulo IA
v1: 95% del tráfico
v2: 5% (canary/IA)
──────────────────
si métricas OK →
v1: 50% | v2: 50%
──────────────────
v2: 100% tráfico ✓
v2: 5% (canary/IA)
──────────────────
si métricas OK →
v1: 50% | v2: 50%
──────────────────
v2: 100% tráfico ✓
✓ Detecta bugs IA reales
✓ Sin 2x infra extra
✓ Feature flags posibles
✗ Requiere split tráfico
Recomendación: Canary + Rolling combinados
Dado que el módulo de IA puede tener edge cases y no quieres duplicar infraestructura (blue-green queda descartado),
aplica Canary al 5% durante las primeras 2 horas de producción con el nuevo scoring de leads. Monitoriza error rate, latencia p99
y tasa de conversión. Si las métricas son estables, escala al 50% y finalmente al 100% mediante un rolling deployment
progresivo. Las migraciones DB son aditivas, por lo que la compatibilidad backward está garantizada durante la transición.
2 · Progresión del tráfico canary
Hora 0 — Inicio
Lanzar, observar logs
Hora 2 — Revisión
Métricas OK ✓
Hora 4 — Mitad
Error rate < 0.1%
Hora 6 — Final
Rollout completo
3 · CI/CD Pipeline — GitHub Actions
Pull Request → main
lint
→
typecheck
→
unit tests
→
integration
→
preview deploy
Merge a main
lint + tests
→
build image
→
push ghcr.io
→
deploy staging
→
smoke tests
→
aprobación manual
→
canary 5%
→
prod 100%
4 · Dockerfile multi-stage (LeadFlow API)
Dockerfile
DOCKER
1# Stage 1: deps
2FROM node:22-alpine AS deps
3WORKDIR /app
4COPY package.json package-lock.json ./
5RUN npm ci --production=false
6
7# Stage 2: build
8FROM node:22-alpine AS builder
9WORKDIR /app
10COPY --from=deps /app/node_modules ./node_modules
11COPY . .
12RUN npm run build && npm prune --production
13
14# Stage 3: runner (sin dev-deps)
15FROM node:22-alpine AS runner
16WORKDIR /app
17RUN addgroup -g 1001 -S appgroup && \
18 adduser -S appuser -u 1001
19USER appuser
20COPY --from=builder --chown=appuser /app/dist ./dist
21COPY --from=builder --chown=appuser /app/node_modules ./
22ENV NODE_ENV=production PORT=3000
23EXPOSE 3000
24HEALTHCHECK --interval=30s --timeout=3s \
25 CMD wget -qO- http://localhost:3000/health || exit 1
26CMD ["node", "dist/server.js"]
5 · Health check endpoint (TypeScript)
routes/health.ts
TYPESCRIPT
1// GET /health — liveness simple
2app.get("/health", (req, res) => {
3 res.json({ status: "ok" });
4});
5
6// GET /health/detailed — readiness completa
7app.get("/health/detailed", async (req, res) => {
8 const checks = {
9 db: await checkDatabase(),
10 redis: await checkRedis(),
11 ai: await checkAiService(), // nuevo
12 };
13 const ok = Object.values(checks)
14 .every(c => c.status === "ok");
15 res.status(ok ? 200 : 503).json({
16 status: ok ? "ok" : "degraded",
17 version: process.env.APP_VERSION,
18 uptime: process.uptime(),
19 checks,
20 });
21});
22
23// Zod validation al arrancar
24const env = envSchema.parse(process.env);
6 · Kubernetes probes (deployment.yaml)
k8s/deployment.yaml — probes
YAML
1livenessProbe:
2 httpGet: { path: /health, port: 3000 }
3 initialDelaySeconds: 10
4 periodSeconds: 30
5 failureThreshold: 3
6
7readinessProbe:
8 httpGet: { path: /health/detailed, port: 3000 }
9 initialDelaySeconds: 5
10 periodSeconds: 10
11 failureThreshold: 2
12
13startupProbe:
14 httpGet: { path: /health, port: 3000 }
15 periodSeconds: 5
16 failureThreshold: 30 # max 150s startup
k8s/deployment.yaml — strategy
YAML
1strategy:
2 type: RollingUpdate
3 rollingUpdate:
4 maxUnavailable: 0 # nunca 0 pods
5 maxSurge: 1 # 1 pod extra
6
7# Canary via Argo Rollouts
8strategy:
9 canary:
10 steps:
11 - setWeight: 5
12 - pause: { duration: 2h }
13 - setWeight: 30
14 - pause: { duration: 2h }
15 - setWeight: 100
7 · Plan de rollback (tiempo objetivo: < 5 min)
1
Detectar alerta
Error rate > 1% o latencia p99 > 2s durante 5 minutos. Alerta en PagerDuty.
kubectl get events --sort-by='.lastTimestamp'
T+0 min
2
Pausar canary
Detener la progresión del tráfico al canary. Sin interrumpir el 95% existente.
kubectl argo rollouts pause leadflow-api
T+2 min
3
Ejecutar rollback
Revertir al SHA anterior. Imagen en ghcr.io disponible y etiquetada.
kubectl argo rollouts abort leadflow-api && kubectl rollout undo deploy/leadflow-api
T+3 min
4
Verificar + postmortem
Confirmar /health 200, métricas estables. Abrir issue con logs del incidente.
kubectl rollout status deploy/leadflow-api
T+5 min
8 · Checklist de preparación para producción — LeadFlow v2.0
Aplicación
✓
Tests unitarios y de integración pasando (98% cobertura)
✓
Endpoint /health retorna estado significativo (DB + Redis + AI)
✓
Sin secretos hardcodeados — validados con Zod al arrancar
!
E2E del flujo de scoring IA en staging (pendiente)
✓
Logs estructurados JSON, sin PII en payloads
Infraestructura
✓
Dockerfile multi-stage con node:22-alpine (versión fijada)
✓
Resource limits configurados (CPU: 500m, Mem: 512Mi)
✓
HPA configurado (min: 2, max: 8 réplicas)
!
SSL en todos los endpoints (verificar renovación cert)
✓
Variables de entorno documentadas en .env.example
Monitorización
✓
Métricas exportadas: request rate, latencia, error rate
✓
Alerta PagerDuty: error rate > 1% durante 5 min
!
Alerta de latencia p99 > 2s para el nuevo módulo IA
✓
Uptime monitoring en Betterstack (cada 30s)
✓
Log aggregation en Loki + Grafana (logs buscables)
Seguridad + Operaciones
✓
Dependencias escaneadas con Trivy (0 CVEs críticos)
✓
Rate limiting en endpoints públicos (100 req/min)
✓
CORS restringido a dominios permitidos
✓
Rollback plan documentado y probado en staging
!
Runbook del módulo IA en Notion (en progreso)
Estado del checklist:
16 ítems completados ·
4 pendientes ·
Bloqueo para producción: 0
80%