Plantilla de Checklist Post-Deploy

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

Resumen

Un deployment no está completo cuando el código llega a producción — está completo cuando has verificado que producción se comporta como esperabas. La verificación post-deployment detecta issues que los tests de CI no ven: mismatches de configuración, variables de entorno faltantes, integraciones rotas y regresiones de performance bajo tráfico real.

Esta plantilla cubre:

1. Health checks — conectividad de aplicación, base de datos y dependencias
2. Smoke tests — paths críticos de usuario bajo condiciones reales
3. Validación de métricas — tasas de error, latencia, uso de recursos
4. Rollback readiness — puedes revertir rápidamente si algo sale mal?
5. Sign-off — quién aprobó el deployment y cuándo

Cuándo Usar

• Cada deployment a producción — sin excepciones, incluso para cambios pequeños
• Deployments a staging — verifica antes de promover a producción
• Cambios de infraestructura — updates de configuración, scaling events, cambios de DNS
• Migraciones de base de datos — verifica que cambios de schema no rompieron queries
• Verificación de rollback — confirma que el rollback restauró el comportamiento esperado
• Después de hotfixes — incluso fixes urgentes necesitan verificación antes de sign-off

Plantilla

# Verificación Post-Deploy: [Servicio] v[X.Y.Z]

## Info del Deployment
| Campo | Valor |
|-------|-------|
| **Deployer** | [nombre] |
| **Timestamp** | [AAAA-MM-DD HH:MM UTC] |
| **Ambiente** | [staging / producción] |
| **Commit de rollback** | [SHA] |

## Health Checks

- [ ] Aplicación inicia sin errores
- [ ] Health endpoint retorna 200: `GET /health`
- [ ] Readiness probe pasa
- [ ] Liveness probe pasa
- [ ] Conectividad a base de datos confirmada
- [ ] Conectividad a dependencias externas confirmada

## Smoke Tests

- [ ] Flujo core de usuario: [login → acción → logout]
- [ ] API retorna status codes esperados
- [ ] Flujo crítico de pagos
- [ ] Admin dashboard carga

## Validación de Métricas

| Métrica | Pre-Deploy | Post-Deploy | Delta | Alerta? |
|---------|-----------|-------------|-------|---------|
| Tasa de error | 0.05% | ___ | ___ | ___ |
| Latencia p95 | 120ms | ___ | ___ | ___ |
| Uso de CPU | 45% | ___ | ___ | ___ |

## Rollback Readiness

- [ ] Script de rollback testeado en últimos 30 días
- [ ] Artefactos de versión anterior disponibles
- [ ] Migración de base de datos es backward-compatible
- [ ] Feature flags pueden deshabilitar nuevo código instantáneamente

## Sign-Off

| Rol | Nombre | Hora |
|------|--------|------|
| Deployer | | |
| On-call | | |

Lifecycle

Preparación pre-deploy

Antes de deployar, completa la sección de info del deployment. Confirma rollback readiness. Asegura coverage de on-call. Configura baselines de métricas para comparación.

Deploy y verificación inmediata

Ejecuta health checks inmediatamente después del deploy. Si cualquier check falla, detente e investiga. No procedas a smoke tests hasta que los health checks pasen.

Monitoreo post-deploy

Ejecuta smoke tests a los 5 minutos, validación de métricas a los 15 minutos. Continúa monitoreando por 1 hora mínimo. Para cambios de alto riesgo, extiende a 24 horas.

Sign-off y archival

Una vez que todos los checks pasan, recolecta sign-offs del deployer y on-call. Archiva el checklist en el log de deployment. Enlázalo a las release notes y cualquier ADR relacionado.

Ejemplo Completo

# Verificación Post-Deploy: payments-api v3.2.1

## Info del Deployment
| Campo | Valor |
|-------|-------|
| **Deployer** | Jane Doe |
| **Timestamp** | 2026-07-15 14:30 UTC |
| **Ambiente** | producción |
| **Commit de rollback** | a1b2c3d4e5f6 |

## Health Checks

- [x] Aplicación inicia sin errores
- [x] Health endpoint retorna 200: `GET /health`
- [x] Readiness probe pasa
- [x] Liveness probe pasa
- [x] Conectividad a base de datos confirmada
- [x] Conectividad a dependencias externas confirmada (Stripe, PayPal)

## Smoke Tests

- [x] Flujo core: login → crear orden → checkout → logout
- [x] API retorna status codes esperados (200, 201, 400, 401, 500)
- [x] Path crítico: flujo de pago con tarjeta de crédito
- [x] Admin dashboard carga con nuevas métricas

## Validación de Métricas

| Métrica | Pre-Deploy | Post-Deploy | Delta | Alerta? |
|---------|-----------|-------------|-------|---------|
| Tasa de error | 0.05% | 0.04% | -0.01% | No |
| Latencia p95 | 120ms | 118ms | -2ms | No |
| Uso de CPU | 45% | 48% | +3% | No |
| Memoria | 512MB | 520MB | +8MB | No |
| Throughput | 850 req/s | 860 req/s | +10 | No |

## Rollback Readiness

- [x] Script de rollback testeado en últimos 30 días
- [x] Artefactos de versión anterior disponibles (v3.2.0)
- [x] Migración de base de datos es backward-compatible
- [x] Feature flags pueden deshabilitar nuevo código instantáneamente

## Sign-Off

| Rol | Nombre | Hora |
|------|--------|------|
| 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 deploy	2 minutos
Smoke tests	5 minutos post-deploy	10 minutos
Validación de métricas	15 minutos post-deploy	10 minutos
Validación completa	1 hora post-deploy	Monitoreo continuo

Lo que funciona

• Automatiza el checklist — CI debería fallar el deploy si los health checks no pasan. Consulta la Guía de CI/CD Pipeline para integración.
• Testea rollback antes de necesitarlo — un rollback que nunca testeaste es una apuesta. Consulta la Plantilla de Plan de Recuperación ante Desastres para planificación amplia.
• Mantén la versión anterior warm — deployments blue-green te permiten volver instantáneamente. Consulta la Guía de Estrategias de Deployment para patrones.
• Usa monitoreo sintético — probes externos detectan issues que tus checks internos no ven
• Documenta actual vs esperado — las desviaciones se convierten en datos de respuesta a incidentes
• Configura thresholds de alerta antes de deployar — sabe qué es “normal” para la nueva versión
• Ten un timer de decisión de rollback — si las métricas degradan en 15 minutos, roll back automático

Errores Comunes

• Saltarse verificación porque “los tests pasaron” — el tráfico de producción es la prueba real
• No chequear tasas de error post-deploy — un deploy que incrementa errores en 0.1% es un deploy fallido
• Asumir que rollback es trivial — testea tu procedimiento de rollback trimestralmente. Para planificación de desastres, consulta la Plantilla de Plan de Recuperación ante Desastres.
• Deployar sin coverage de on-call — si la verificación falla, alguien debe estar disponible para responder
• Chequear muy pocas métricas — CPU y error rate no son suficientes; chequea métricas de negocio también
• Sin criterios de decisión de rollback — define qué dispara un rollback automático antes de deployar

Variantes

Verificación de deployment canary

Para deployments canary, compara métricas entre el grupo canary y el grupo estable. Monitorea delta de error rate, delta de latencia y feedback de usuarios. Roll back del canary si cualquier métrica degrada más allá del threshold. Escala gradualmente: 1% → 5% → 25% → 50% → 100%.

Verificación de deployment blue-green

Para deployments blue-green, corre la nueva versión (green) junto a la vieja (blue). Rutea una porción de tráfico a green, verifica, luego switcha el router. Mantén blue corriendo para rollback instantáneo si green muestra issues.

Verificación de migración de base de datos

Para deployments con cambios de schema, verifica: migración completada, backward compatibility, performance de queries y uso de índices. Ten un script de migración de rollback testeado en staging. Consulta la Plantilla de Documentación de Schema de Base de Datos para tracking de schema.

Automatización

Integración CI/CD

post-deploy-verification:
  stage: post-deploy
  script:
    - curl -f https://api.example.com/health || exit 1
    - npm run smoke-tests -- --env=production
    - npm run check-metrics -- --threshold=baseline.json
  after_script:
    - npm run notify-team -- --status=$CI_JOB_STATUS
  only:
    - main

Probes de health automatizados

Configura monitoreo sintético que hit tus health endpoints cada 60 segundos. Configura alertas para cualquier respuesta non-200. Usa herramientas como Pingdom, UptimeRobot o AWS CloudWatch Synthetics.

Auto-rollback basado en métricas

Configura tu sistema de deployment para auto-rollback cuando el error rate exceda un umbral dentro de los primeros 15 minutos. Kubernetes canaries con Argo Rollouts o AWS CodeDeploy soportan esto nativamente.

Lectura Adicional

• Documentación oficial: consulta la referencia actualizada del framework o herramienta utilizada.
• Guías relacionadas: explora las guías de deployment y devops para profundizar.
• Patrones complementarios: revisa los patrones de diseño aplicables a tu stack tecnológico.
• Postmortems públicos: estudia incidentes reales de equipos que enfrentaron problemas similares en producción.

Notas de Producción

• Despliega gradualmente usando canary o blue-green para detectar regresiones temprano.
• Configura alertas para errores, latencia p99 y tasa de fallos antes de habilitar en producción.
• Documenta el rollback en el runbook; prueba el procedimiento en staging al menos una vez por trimestre.
• Revisa logs estructurados con correlation IDs para trazar requests end-to-end en incidentes.

Puntos Clave

• Aplica plantilla de checklist post-deploy cuando necesites una solución práctica para tu caso de uso.
• Monitorea el rendimiento después de implementar; mide latencia, errores y uso de recursos antes y después.
• Revisa la sección de Troubleshooting ante errores comunes; la mayoría tienen causa raíz documentada con solución.
• Mantén dependencias actualizadas y ejecuta tests en CI para prevenir regresiones en producción.

Troubleshooting

• Pipeline fails silently: enable verbose logging and store pipeline artifacts between stages so you can inspect the exact state that failed.
• Container crashes on startup: check that environment variables, secrets, and config files are mounted correctly. Read the first 50 lines of logs before scaling replicas.
• Deployment rolls back repeatedly: verify health checks, resource limits, and startup probes. A failing readiness probe is a common cause of rolling restarts.
• Slow CI builds: cache dependencies and docker layers. Split large test suites into parallel jobs to reduce wall-clock time.
• Drift between environments: use infrastructure-as-code and immutable artifacts.

Errores Comunes en Producción

• Dejar campos requeridos vacíos o usar respuestas vagas de una palabra.
• Llenar el documento una vez y nunca actualizarlo cuando cambia el alcance o las decisiones.
• Guardar el documento donde el equipo no lo busque durante incidentes o revisiones.
• No asignar un responsable, fecha límite o cadencia de revisión.
• Copiar texto base sin eliminar secciones que no aplican.
• Saltar el control de versiones, lo que impide rollback y responsabilidad.
• No vincular el documento con decisiones relacionadas o acciones de seguimiento.
• Evitar revisiones trimestrales que retirarían secciones obsoletas o sin uso.