Estrategia de rollback: el paso del deploy que nadie escribe
Todo equipo tiene un pipeline de deploy. Pocos tienen una estrategia de rollback que funcione a las 2 a.m. Rollback no es un script en el repo — son triggers, autoridad, rutas de revert de app y compatibilidad de schema decididas antes de que salga el release.
Los pipelines de deploy se ensayan cada sprint. El rollback se documenta una vez en una wiki que nadie abre durante incidentes. La asimetría aparece cuando las tasas de error suben doce minutos después de un release: ingenieros debaten si revertir, si la migración es reversible, quién tiene autoridad para decidirlo y si down.sql se testeó alguna vez contra datos con forma de producción. La estrategia de rollback para deploy es el artefacto faltante — no otro script, sino un árbol de decisión escrito antes del release, con triggers, responsables, acciones seguras, acciones inseguras y pasos de verificación lo bastante cortos para ejecutar bajo presión.
El rollback de aplicación es rápido cuando los artefactos son inmutables y etiquetados. El rollback de datos es lento, a veces imposible, y suele ser la restricción real. Una estrategia de rollback que solo aborda código — "redeploy del tag anterior" — falla la primera vez que una migración eliminó una columna que el binario viejo aún lee.
El rollback falla cuando schema y código se mueven juntos sin plan
Los deploys modernos tocan dos superficies: binarios de aplicación y schema de base de datos. Hacen rollback a velocidades distintas y con perfiles de seguridad distintos.
| Superficie | Mecanismo de rollback | Tiempo típico | Riesgo |
|---|---|---|---|
| Aplicación | Redeploy de tag / imagen anterior | 2–15 minutos | Bajo si existe el artefacto |
| Feature flags | Apagar toggle | Segundos | Bajo para rutas gated por flag |
| Schema (expand) | Código viejo sigue funcionando | N/A — forward compatible | Bajo durante fase expand |
| Schema (contract) | Irreversible sin pérdida de datos | Horas a nunca | Alto |
| Data backfill | Forward fix o restore | Horas | Muy alto |
Las migraciones expand/contract existen porque el rollback de schema es difícil. Expand añade schema nuevo junto al viejo — columna nullable, tabla nueva, ruta de dual-write. Migrate mueve tráfico y datos gradualmente. Contract elimina schema viejo solo tras probar que nada lo lee. Rollback durante expand suele significar revertir código de aplicación dejando columnas nuevas en su lugar — seguro si las columnas son nullable e ignoradas por código viejo. Rollback durante contract puede ser imposible sin restore desde backup.
Una down migration que nadie ejecutó en staging no es un plan de rollback. Es esperanza.
El patrón de feature flags como infraestructura de release reduce la necesidad de rollback de código para rutas user-facing — apagar el toggle en segundos. No revierte cambios de schema. Flags y estrategia de rollback se complementan; ninguno reemplaza al otro.
Una estrategia de rollback es un árbol de decisión de una página
El runbook cabe en una página porque nadie lee prosa durante incidentes.
Bloque de encabezado
- Versión y tag del release
- Identificadores de migraciones aplicadas
- Responsable de rollback y autoridad de respaldo
- Fase expand/contract actual
Triggers — cuándo hacer rollback
Definir umbrales numéricos, no "si algo se ve mal":
- Tasa de error en endpoints afectados > 2× baseline por 5 minutos
- Latencia p99 > 1.5× baseline por 10 minutos
- Cualquier aumento sostenido en tasa de fallo de pago o auth
- Fallo de test funcional user-facing post-deploy
- Trigger manual: ingeniero on-call o responsable del release
Ramas de decisión
Trigger fired?
├─ Feature-flagged path only → Toggle flag OFF (30 sec)
│ └─ Verify metrics → Done or escalate to app rollback
├─ App bug, schema forward-compatible → Redeploy previous tag
│ └─ Run smoke tests → Monitor 30 min
├─ App bug, schema NOT compatible → Forward-fix OR restore (see unsafe)
└─ Migration caused issue → STOP app rollback if unsafe
├─ Expand phase → Revert app; pause backfill; schema stays
└─ Contract phase → Forward-fix migration; do NOT run down.sql
Acciones inseguras — listar explícitamente
- Ejecutar migraciones
downno testeadas contra producción - Eliminar columnas para "coincidir" con código viejo tras escribir datos en schema nuevo
- Revertir app mientras workers en background escriben datos en formato nuevo
- Restaurar backup de base de datos sin coordinar versión de app
Verificación tras rollback
- Checklist de smoke tests (auth, CRUD core, pago si aplica)
- Comparar tasa de error y latencia con baseline pre-deploy
- Query que confirme ausencia de estados de datos huérfanos (p. ej., filas atascadas en status
migrating) - Comunicación: quién notifica stakeholders, qué publicar en status page
Ensayar el árbol una vez por trimestre. Rollback no testeado es folklore.
El rollback de aplicación requiere artefactos inmutables
Redeploy de versión anterior solo funciona si la versión anterior existe y se sabe que es buena.
- Etiquetar cada deploy de producción:
v1.4.2en imagen de contenedor inmutable o artefacto de build. - Registrar el último tag conocido como bueno en release notes — no "lo que hubiera antes."
- CI produce el mismo artefacto para un tag dado para siempre — sin rebuild-from-source durante incidentes salvo fallo del registry de artefactos.
- Smoke tests corren automáticamente contra el deploy nuevo; definir si bloquean o solo advierten.
Objetivo: rollback de aplicación completo en menos de quince minutos desde trigger hasta recuperación verificada. Si el pipeline tarda cuarenta minutos, la estrategia de rollback es teórica.
Los cambios de base de datos usan forward-fix cuando el rollback hacia atrás es inseguro: enviar una migración nueva que repara estado, mantener app en versión fallida o hacer rollback de app por separado según compatibilidad. rollback de Liquibase y archivos down de frameworks son herramientas de desarrollo — incidentes de producción necesitan rutas forward revisadas, no SQL inverso autogenerado contra datos en vivo.
El rollback de schema se coordina con la versión de app
La matriz de compatibilidad debe escribirse antes del deploy:
| Versión app | Versión schema | ¿Seguro? |
|---|---|---|
| N+1 | expand (col nullable nueva) | Sí — deploy de app nueva |
| N | expand (col nullable nueva) | Sí — app vieja ignora col nueva |
| N | contract (col eliminada) | No — app vieja se rompe |
| N+1 | schema N | Suele ser sí si N+1 es backward compatible |
Si la migración N+1 no es backward compatible con app N, rollback simultáneo requiere forward-fix, no solo revert de tag. Coordinar secretos de CI/CD y acceso al pipeline — deploys de rollback usan las mismas rutas privilegiadas que deploys forward; proteger ambas por igual.
¿Qué debe incluir un runbook de rollback en producción?
Estos elementos separan recuperación ensayada de daño improvisado.
¿Quién puede autorizar rollback?
Nombrar autoridad primaria y de respaldo — ingeniero on-call, responsable del release o lead de ingeniería. "Consenso del equipo" no es autoridad a las 2 a.m. Triggers preautorizados (apagado automático de flag ante umbral de error) reducen debate en rutas conocidas.
¿Cuándo es seguro el rollback de app tras una migración?
Seguro cuando la migración está en fase expand y es backward compatible: código viejo ignora elementos de schema nuevos, sin columnas nuevas requeridas en rutas de escritura que usa código viejo, sin datos exclusivamente en tablas nuevas que código viejo no puede leer. Inseguro cuando corrió fase contract, cuando backfill escribió datos que código viejo malinterpreta, o cuando la down migration nunca se testeó.
¿Cuál es la ruta forward-fix cuando rollback es imposible?
Documentar: rama hotfix, migración para reparar datos, deploy de versión hotfix de app, queries de verificación, estimación de timeline. Restore point-in-time de base de datos es último recurso — nombrar RPO/RTO, quién invoca restore, cómo alinea versión de app con snapshot de datos restaurado.
Una visión opuesta
La postura contraria sostiene que la cultura de rollback fomenta deploys temerarios — que los equipos deberían invertir en nunca necesitar rollback mediante mejor testing, canary deploys y feature flags.
Canary y flags reducen frecuencia de rollback. No lo eliminan. Misconfiguración de infraestructura, caídas de terceros enmascaradas como errores de código y edge cases de migración siguen ocurriendo. La estrategia de rollback es seguro — el objetivo es nunca usarla; el requisito es que funcione cuando haga falta.
Cero incidentes de rollback no es la métrica. El tiempo medio de recuperación cuando rollback es la decisión correcta sí lo es.
Key takeaways
- La estrategia de rollback es un árbol de decisión de una página — triggers, autoridad, ramas, acciones inseguras.
- Rollback de aplicación necesita artefactos inmutables etiquetados; rollback de schema necesita disciplina expand/contract.
- Down migrations no testeadas en producción no son planes de rollback.
- Feature flags revierten exposición en segundos; no revierten schema.
- Definir triggers numéricos, no "se ve mal" subjetivo.
- Ensayar rollback trimestralmente; forward-fix es la ruta segura cuando corrió fase contract.
Conclusion
Los pipelines de deploy se practican porque corren cada semana. El rollback se ignora porque es incómodo imaginar el fallo. Los equipos que se recuperan en minutos escribieron la parte incómoda antes del incidente: qué revertir, qué nunca revertir, quién decide y cómo verificar recuperación.
El próximo release debería salir con una sección de rollback en las release notes — no después. Si la sección está vacía porque "ya lo veremos," el release no está listo.