Rollback
Volver a la última versión que andaba cuando una nueva trae problemas.
Un rollback es deshacer un cambio devolviendo un sistema a un estado anterior que se sabe que funcionaba. El caso más común son los lanzamientos de software: un equipo publica la versión 3 de una app, empiezan a llover reportes de errores y, en lugar de buscar el bug mientras los usuarios la sufren, vuelven a poner la versión 2. La investigación se puede hacer después, con calma.
Poder hacer rollback rápido es una de las mejores redes de seguridad que puede tener un equipo, y las herramientas actuales lo vuelven rutina. Kubernetes guarda las versiones anteriores de un deployment y puede volver a una con un solo comando. Los servicios de despliegue en la nube pueden hacer rollback solos cuando fallan los chequeos de salud o saltan alarmas. Formas de lanzar como los canary releases y los despliegues blue-green están pensadas, en parte, para que volver atrás sea rápido y el problema lo noten pocos usuarios.
La parte difícil suele ser la de los datos. El código se puede cambiar en segundos, pero si la versión 3 modificó la base de datos, por ejemplo renombrando una columna, puede que la versión 2 ya no la entienda. Por eso los equipos prolijos hacen los cambios en la base en pasos chicos y compatibles hacia atrás. A veces volver no se puede o no conviene, y el equipo prefiere "ir para adelante" con un arreglo rápido. La palabra también se usa en bases de datos: a una transacción que falla se le hace rollback, así no queda guardado ninguno de sus cambios.
Para quedarse
- Devuelve un sistema a la última versión que se sabe que funcionaba.
- Corta el síntoma rápido; la causa de fondo se investiga después.
- Los cambios en la base de datos son lo que suele complicar el rollback.
- En bases de datos, a una transacción fallida se le hace rollback para no dejar nada a medias.
Para seguir leyendo
- Deployments en Kubernetes (documentación oficial)
- Volver a implementar y revertir una implementación con CodeDeploy (documentación de AWS)