Plantilla de Checklist Post-Deploy

Usa este checklist antes de declarar un despliegue exitoso. Combínalo con la Plantilla de Release Notes para la comunicación y con la Guía de CI/CD Pipeline para la automatización.

Resumen

Un despliegue no termina cuando el código llega a producción: termina cuando verificaste que producción se comporta como esperabas. La verificación post-deploy detecta lo que los tests de CI no pueden: discrepancias de configuración, variables de entorno que faltan, integraciones rotas y regresiones de rendimiento que solo aparecen con tráfico real.

Esta plantilla cubre seis áreas:

1. Health checks — conectividad de la aplicación, la base de datos y las dependencias
2. Smoke tests — rutas críticas de usuario en condiciones reales
3. Validación de métricas — tasas de error, latencia y uso de recursos
4. Seguridad y logs — cabeceras, certificados y nuevos patrones de error
5. Preparación de rollback — si puedes revertir rápido cuando algo se rompe
6. Sign-off — quién verificó el despliegue y cuándo

Copia la plantilla de abajo, conserva las secciones que apliquen a tu stack y conecta los checks automáticos en CI para que el checklist se ejecute igual cada vez.

Cuándo Usar

• Cada despliegue a producción — sin excepciones, incluso para cambios pequeños
• Despliegues a staging — verifica antes de promover a producción
• Cambios de infraestructura — actualizaciones de configuración, eventos de escalado, cambios de DNS
• Migraciones de base de datos — confirma que los cambios de esquema no rompieron las queries
• Verificación de rollback — confirma que el rollback restauró el comportamiento esperado
• Después de hotfixes — los fixes urgentes también necesitan verificación antes del sign-off

El único caso donde esto no aplica es un cambio que nunca llega a producción: un commit de documentación, un fix de README, una rama solo de tests. Todo lo demás se verifica.

Plantilla

# Post-Deployment Verification: [Service] v[X.Y.Z]

## Deployment Info
| Field | Value |
|-------|-------|
| **Deployer** | [name] |
| **Timestamp** | [YYYY-MM-DD HH:MM UTC] |
| **Environment** | [staging / production] |
| **Rollback commit** | [SHA] |

## Health Checks

- [ ] Application starts without errors
- [ ] Health endpoint returns 200: `GET /health`
- [ ] Readiness probe passes
- [ ] Liveness probe passes
- [ ] Database connectivity confirmed
- [ ] External dependency connectivity confirmed

## Smoke Tests

- [ ] Core user flow: [login → action → logout]
- [ ] API returns expected status codes
- [ ] Critical path payment flow
- [ ] Admin dashboard loads

## Metrics Validation

| Metric | Pre-Deploy | Post-Deploy | Delta | Alert? |
|--------|-----------|-------------|-------|--------|
| Error rate | 0.05% | ___ | ___ | ___ |
| Latency p95 | 120ms | ___ | ___ | ___ |
| CPU usage | 45% | ___ | ___ | ___ |

## Security & Logs

- [ ] Security headers present on key routes (`curl -I` shows CSP, HSTS)
- [ ] TLS certificate valid, expiry > 30 days
- [ ] No spike in 401/403 responses vs pre-deploy baseline
- [ ] No new exception patterns in application logs
- [ ] No secrets or credentials leaked in logs

## Rollback Readiness

- [ ] Rollback script tested in last 30 days
- [ ] Previous version artifacts available
- [ ] Database migration is backward-compatible
- [ ] Feature flags can disable new code instantly

## Sign-Off

| Role | Name | Time |
|------|------|------|
| Deployer | | |
| On-call | | |

Ciclo de Vida

El bloque de Seguridad y Logs es más nuevo que los demás: agrégalo aunque tu equipo nunca lo haya completado. Los despliegues que rompen TLS, eliminan una cabecera o empiezan a loguear tokens no aparecen en un /health; aparecen en un informe de brecha un mes después.

Preparación previa al despliegue

Antes de desplegar, completa la sección de información del despliegue. Confirma la preparación del rollback: un rollback que nunca se probó no es un rollback, es una esperanza. Asegúrate de que haya alguien de guardia y registra las métricas de referencia para tener con qué comparar.

Despliegue y verificación inmediata

Ejecuta los health checks apenas termina el despliegue. Si algún check falla, detente e investiga. No pases a los smoke tests hasta que los health checks pasen: un servicio que no está sano va a fallar todos los checks posteriores de todos modos.

Monitoreo post-deploy

Ejecuta los smoke tests a los 5 minutos y la validación de métricas a los 15. Sigue observando al menos 1 hora; extiende a 24 horas para cambios de alto riesgo como migraciones de esquema o flujos de pago. Lo que observas en esa ventana no es solo “¿sigue funcionando?”: son las señales lentas — la memoria subiendo de forma sostenida, la tasa de error derivando hacia arriba, las colas acumulando trabajo. Eso no dispara un health check, pero aparece en las gráficas antes de que llegue a las quejas de los usuarios.

Sign-off y archivo

Cuando todos los checks pasan, recolecta los sign-offs del responsable del despliegue y del ingeniero de guardia. Archiva el checklist completado en el registro de despliegues y enlázalo a las release notes y a los ADRs relacionados: es la evidencia si en una revisión de incidente preguntan “¿esto se verificó?”

Adaptar el checklist al riesgo

No todo despliegue merece la ceremonia completa. Escala el checklist según lo que realmente podría romperse:

Nivel de riesgo	Ejemplos	Alcance
Bajo	Cambios de contenido, retoques de CSS, flags de configuración	Health checks + smoke test puntual
Medio	Endpoints nuevos, actualizaciones de dependencias, cambios de infra	Checklist completo
Alto	Migraciones de esquema, flujos de pago, cambios de auth	Checklist completo + monitoreo 24 h + tercer sign-off

Ante la duda, corre la versión completa: el checklist cuesta diez minutos; un problema de producción no detectado le cuesta la noche al de guardia.

Comandos de Verificación

Los ítems del checklist son el qué; estos snippets son el cómo. Adapta las URLs y los umbrales a tu stack.

Endpoint de salud

curl -fsS --retry 3 --retry-delay 2 \
  https://api.example.com/health || echo "HEALTH CHECK FAILED"

Smoke test con k6

// smoke.js — run with: k6 run smoke.js
import http from 'k6/http';
import { check } from 'k6';

export const options = { vus: 1, duration: '30s' };

export default function () {
  const res = http.get('https://api.example.com/health');
  check(res, { 'health is 200': (r) => r.status === 200 });

  const login = http.post('https://api.example.com/login',
    JSON.stringify({ user: 'smoke@test.dev', pass: '***' }),
    { headers: { 'Content-Type': 'application/json' } });
  check(login, { 'login works': (r) => r.status === 200 });
}

Tasa de error desde los access logs

# 5xx share in the last 15 minutes of nginx logs
awk -v cutoff="$(date -d '15 minutes ago' '+%d/%b/%Y:%H:%M')" \
  '$4 > "["cutoff { total++; if ($9 >= 500) errors++ }
   END { printf "%.3f%% (%d/%d)\n", 100*errors/total, errors, total }' \
  /var/log/nginx/access.log

Excepciones nuevas en los logs de la aplicación

# Errors seen post-deploy that didn't appear in the pre-deploy window
grep -i "exception\|error" /var/log/app/current.log | \
  awk '{print $NF}' | sort | uniq -c | sort -rn | head -10

Si alguno de estos falla, la fila del checklist falla: márcala, investiga y decide entre rollback y fix-forward antes del sign-off.

Ejemplo Completo

# Post-Deployment Verification: payments-api v3.2.1

## Deployment Info
| Field | Value |
|-------|-------|
| **Deployer** | Jane Doe |
| **Timestamp** | 2026-07-15 14:30 UTC |
| **Environment** | production |
| **Rollback commit** | a1b2c3d4e5f6 |

## Health Checks

- [x] Application starts without errors
- [x] Health endpoint returns 200: `GET /health`
- [x] Readiness probe passes
- [x] Liveness probe passes
- [x] Database connectivity confirmed
- [x] External dependency connectivity confirmed (Stripe, PayPal)

## Smoke Tests

- [x] Core user flow: login → create order → checkout → logout
- [x] API returns expected status codes (200, 201, 400, 401, 500)
- [x] Critical path: credit card payment flow
- [x] Admin dashboard loads with new metrics

## Metrics Validation

| Metric | Pre-Deploy | Post-Deploy | Delta | Alert? |
|--------|-----------|-------------|-------|--------|
| Error rate | 0.05% | 0.04% | -0.01% | No |
| Latency p95 | 120ms | 118ms | -2ms | No |
| CPU usage | 45% | 48% | +3% | No |
| Memory | 512MB | 520MB | +8MB | No |
| Throughput | 850 req/s | 860 req/s | +10 | No |

## Security & Logs

- [x] Security headers present (`curl -I https://api.example.com` → CSP + HSTS)
- [x] TLS certificate valid until 2027-01-20
- [x] 401/403 rate unchanged (0.8% pre, 0.7% post)
- [x] No new exception patterns (checked `payments-api` error log)
- [x] No secrets in logs

## Rollback Readiness

- [x] Rollback script tested in last 30 days
- [x] Previous version artifacts available (v3.2.0)
- [x] Database migration is backward-compatible
- [x] Feature flags can disable new code instantly

## Sign-Off

| Role | Name | Time |
|------|------|------|
| Deployer | Jane Doe | 14:35 UTC |
| On-call | Bob Smith | 14:40 UTC |

Guías de Timing

Tipo de check	Cuándo	Duración
Health checks	Inmediatamente después del despliegue	2 minutos
Smoke tests	5 minutos post-deploy	10 minutos
Validación de métricas	15 minutos post-deploy	10 minutos
Revisión de seguridad y logs	15 minutos post-deploy	5 minutos
Validación completa	1 hora post-deploy	Monitoreo continuo

Variantes

Verificación de despliegue canary

En los despliegues canary, compara las métricas entre el grupo canary y el grupo estable. Observa el delta de tasa de error, el delta de latencia y el feedback de usuarios. Revierte el canary si alguna métrica se degrada más allá de su umbral y escala de forma gradual: 1% → 5% → 25% → 50% → 100%.

Verificación de despliegue blue-green

En los despliegues blue-green, la versión nueva (green) corre junto a la anterior (blue). Enruta una porción del tráfico a green, verifica y luego conmuta el router. Mantén blue corriendo para poder revertir al instante si green muestra problemas. Para la mecánica del rollout, consulta la receta de Blue-Green Deployment.

Verificación de migración de base de datos

En despliegues con cambios de esquema, verifica: migración completada, compatibilidad hacia atrás, rendimiento de las queries y uso de índices. Ten un script de migración de rollback probado en staging. Consulta la Plantilla de Documentación de Esquema de Base de Datos para el seguimiento de migraciones.

Despliegue de sitio estático o CDN

En sitios estáticos y frontends servidos por CDN, el checklist se acorta pero no desaparece. Verifica que las nuevas versiones de los assets realmente se sirven (prueba una URL con cache-busting y una normal), confirma que las cabeceras de caché son correctas, revisa los redirects y la página 404, y purga la caché del CDN si queda contenido viejo. Omite los checks de base de datos y de sondas por completo.

API detrás de un balanceador de carga

En APIs detrás de un load balancer, drena las conexiones por nodo durante el rollout y verifica el health check de cada nodo individualmente antes de devolver el pool a tráfico completo. Ojo con los nodos que pasan el health check del balanceador pero fallan requests reales: un /health que solo verifica que el proceso vive no detecta un pool de base de datos roto.

Jobs programados y workers

En cron jobs, colas y workers en background, “¿está arriba?” significa otra cosa: el proceso corre pero no hay tráfico para hacer smoke tests. Verifica en cambio que el job realmente se ejecutó: revisa la marca de tiempo de su última corrida, su duración contra la línea base y que la profundidad de la cola baja en lugar de crecer. Un worker vivo que silenciosamente se salta su horario es el fallo clásico aquí.

Lo que funciona

• Automatiza el checklist — el CI debería fallar el despliegue si los health checks no pasan. Consulta la Guía de CI/CD Pipeline para la integración.
• Prueba el rollback antes de necesitarlo — un rollback sin probar es una apuesta. Consulta la Plantilla de Plan de Recuperación ante Desastres para una planificación más amplia.
• Mantén la versión anterior disponible — los despliegues blue-green te permiten volver atrás al instante. Consulta la Guía de Estrategias de Despliegue para los patrones.
• Usa monitoreo sintético — las sondas externas detectan problemas que tus checks internos no ven.
• Registra correlation IDs — etiqueta los despliegues con un correlation ID para poder rastrear errores post-deploy hasta el release en los logs estructurados.
• Documenta lo real vs lo esperado — las desviaciones se convierten en datos de respuesta a incidentes.
• Define umbrales de alerta antes de desplegar — sabe qué es “normal” para la nueva versión.
• Ten un temporizador de decisión de rollback — si las métricas se degradan en 15 minutos, rollback automático.
• Mantén el checklist liviano — un checklist de 50 ítems se hojea; uno de 15 se completa. Corta cualquier ítem sobre el que nadie actuaría jamás.

Errores Comunes

• Saltarse la verificación porque “los tests pasaron” — el tráfico de producción es la prueba real.
• No revisar la tasa de errores después del despliegue — un despliegue que sube los errores un 0,1% es un despliegue fallido.
• Asumir que el rollback es trivial — prueba tu procedimiento de rollback cada trimestre. Para la planificación de desastres, consulta la Plantilla de Plan de Recuperación ante Desastres.
• Desplegar sin cobertura de guardia — si la verificación falla, alguien tiene que estar disponible para responder.
• Revisar muy pocas métricas — CPU y tasa de error no alcanzan; revisa también métricas de negocio.
• Completar el checklist y nunca archivarlo — si el checklist completado no queda guardado con el registro del despliegue, el sign-off no vale nada en una revisión posterior.
• Sin criterios de decisión de rollback — define qué dispara un rollback automático antes de desplegar.

Automatización

Integración con CI/CD

post-deploy-verification:
  stage: post-deploy
  script:
    - curl -fsS --retry 3 https://api.example.com/health || exit 1
    - k6 run smoke.js --env production
    - npm run check-metrics -- --threshold=baseline.json
    - node scripts/scan-error-log.js --since-deploy
  after_script:
    - npm run notify-team -- --status=$CI_JOB_STATUS
  only:
    - main

Sondas de salud automatizadas

Configura monitoreo sintético que golpee tus endpoints de salud cada 60 segundos y alerte ante cualquier respuesta que no sea 200. Pingdom, UptimeRobot y AWS CloudWatch Synthetics lo resuelven sin infraestructura extra.

Rollback automático basado en métricas

Configura tu sistema de despliegue para revertir automáticamente cuando la tasa de errores supere un umbral dentro de los primeros 15 minutos. Los canary de Kubernetes con Argo Rollouts y AWS CodeDeploy soportan esto de forma nativa.

Solución de Problemas

• El pipeline falla en silencio: activa el logging detallado y guarda los artefactos del pipeline entre etapas para poder inspeccionar el estado exacto que falló.
• El contenedor se cae al arrancar: revisa que las variables de entorno, los secretos y los archivos de configuración estén montados correctamente. Lee las primeras 50 líneas de logs antes de escalar réplicas.
• El despliegue hace rollback una y otra vez: verifica health checks, límites de recursos y sondas de arranque. Una sonda de readiness que falla es una causa común de reinicios en bucle.
• Builds de CI lentos: cachea dependencias y capas de Docker. Divide las suites de tests grandes en jobs paralelos para reducir el tiempo total.
• Deriva entre entornos: usa infraestructura como código y artefactos inmutables.
• El health check pasa pero los usuarios ven errores: tu endpoint de salud es demasiado superficial. Añade checks de dependencias (base de datos, caché, colas) en una variante /health/deep y apunta los smoke tests contra ella.

Lectura Adicional

• Google SRE Workbook — Release Engineering — cómo estructura Google la verificación de releases y post-releases.
• Documentación de Argo Rollouts — análisis canary automatizado y rollback basado en métricas para Kubernetes.
• Documentación de despliegues de AWS CodeDeploy — disparadores de auto-rollback y opciones de cambio de tráfico.
• Blue-green deployment — Martin Fowler — el texto de referencia sobre el patrón detrás del rollback instantáneo.

Puntos Clave

• La verificación es lo que marca un despliegue como “terminado”: que el código llegue a producción no es la línea de meta.
• Health checks primero, smoke tests a los 5 minutos, métricas a los 15 — y rollback ante degradación en lugar de depurar en vivo.
• El checklist solo sirve si se archiva con el registro del despliegue y el camino de rollback se probó antes de necesitarlo.