¿Qué es un rollback?

Un rollback es el proceso de revertir un sistema, aplicación o base de datos a un estado anterior conocido y estable, normalmente como respuesta a un error detectado tras un cambio reciente. Cuando una nueva versión introduce un fallo grave, en lugar de intentar arreglarlo en caliente bajo presión, el equipo "vuelve atrás" a la última versión que funcionaba correctamente.

El término se usa sobre todo en dos contextos: el de los despliegues de software (revertir el código de una aplicación) y el de las bases de datos (deshacer una transacción o una migración que dejó los datos en un estado incorrecto). En ambos casos la idea es la misma: recuperar un estado válido lo antes posible para minimizar el impacto en las personas usuarias.

El valor del rollback está en que separa dos decisiones que muchas veces se mezclan bajo presión: restaurar el servicio y entender el problema. Cuando algo falla en producción, lo urgente es que el sistema vuelva a funcionar; el diagnóstico de la causa puede esperar a que la situación esté bajo control.

Si un despliegue rompe el proceso de pago de una tienda online, el equipo puede revertir a la versión anterior y restaurar el cobro en cuestión de minutos, mientras investiga con calma qué falló en la nueva versión. Sin un mecanismo de rollback fiable, esa misma incidencia obligaría a depurar el código en directo, con el negocio parado y el estrés multiplicado.

Por eso el rollback es una pieza central de la fiabilidad y la cultura DevOps: un equipo capaz de revertir con seguridad puede permitirse desplegar más a menudo y con menos miedo, porque sabe que cualquier cambio es reversible.

Un rollback no es magia: requiere haberlo preparado de antemano. Estas son las estrategias más habituales.

• Versionado del código. Con un sistema de control de versiones como Git, cada versión desplegada corresponde a un commit o una etiqueta. Revertir suele consistir en volver a desplegar la versión anterior, no en deshacer el cambio a mano.
• Despliegues con dos entornos. Con una estrategia blue-green mantienes dos entornos productivos; si el nuevo (green) falla, rediriges el tráfico de vuelta al anterior (blue) casi al instante.
• Liberación gradual. Con un canary release expones la versión nueva a una fracción del tráfico; si aparecen errores, detienes el avance y vuelves a la versión estable antes de que afecte a todo el mundo.
• Feature flags. Con un feature flag puedes apagar una funcionalidad concreta sin necesidad de revertir todo el despliegue, lo que da un control mucho más fino.
• Migraciones reversibles de base de datos. Los cambios de esquema deberían diseñarse para poder deshacerse (scripts "up" y "down"), porque revertir el código sin revertir los datos puede dejar el sistema inconsistente.

Lo ideal es que el rollback esté automatizado dentro del pipeline de CI/CD, de modo que un fallo detectado por las métricas o las pruebas dispare la vuelta atrás sin intervención manual, o con un solo botón.

Imagina un equipo que despliega una nueva versión del carrito de compra un viernes por la tarde. A los pocos minutos, el panel de monitorización muestra que los errores en la pasarela de pago se disparan.

1. La persona de guardia confirma por las métricas que el problema empezó justo con el último despliegue.
2. En lugar de buscar el bug en el momento, ejecuta el rollback: el pipeline vuelve a desplegar la versión anterior etiquetada en Git.
3. En pocos minutos la tasa de error vuelve a la normalidad y los clientes pueden volver a pagar.
4. Con el servicio ya estable, el equipo reproduce el fallo en un entorno de pruebas, lo corrige y planifica un nuevo despliegue.

El resultado: minutos de incidencia en vez de horas, y un diagnóstico hecho sin la presión de tener el negocio caído.

• Dar por hecho que el rollback funciona sin probarlo. Un plan de vuelta atrás que nunca se ha ensayado puede fallar justo cuando más lo necesitas. Conviene practicarlo en entornos de prueba.
• Olvidar la base de datos. Revertir el código es fácil; revertir cambios de datos no siempre lo es. Una migración que borra o transforma datos puede ser irreversible si no se diseñó con cuidado.
• Confundir rollback con hotfix. El rollback te devuelve a un estado bueno conocido; un parche en caliente intenta arreglar el problema sobre la versión defectuosa. Bajo presión, casi siempre es más seguro revertir primero y arreglar después.
• No definir quién y cuándo decide revertir. Sin un criterio claro (qué métrica, qué umbral, quién da la orden), el equipo pierde minutos valiosos discutiendo en plena incidencia.

En equipos que trabajan con Scrum o Kanban, tener un plan de rollback suele formar parte de la definición de hecho de cada tarea del backlog: un cambio no se considera realmente "terminado" si no se puede revertir con seguridad. Así, cualquier incremento entregado durante un sprint llega a producción sabiendo que existe una vía de retorno.

El rollback se entiende mejor junto a conceptos como el deploy, el pipeline de CI/CD y las estrategias de despliegue progresivo (blue-green, canary release y feature flags), todas ellas orientadas a entregar valor con frecuencia sin sacrificar la estabilidad.