Rollback (reversión)

Un rollback devuelve un sistema a la última versión que funcionaba bien después de que un release causa problemas.

Un rollback es la respuesta planificada a un mal release. El equipo deja de depurar en producción, restaura la versión anterior y analiza el problema después, sin presión. Qué tan rápido puede ocurrir eso es una de las medidas más útiles de un proceso de entrega.

En un frontend hay varios niveles:

• Apagar un feature flag, que oculta el camino nuevo del código.
• Apuntar el CDN o el servidor al build anterior.
• En una plataforma de microfrontends, apuntar el manifiesto a la versión anterior de un remoto.
• Revertir el commit y correr el pipeline otra vez, que es la opción más lenta.

Ejemplo

El viernes sale una versión nueva del remoto de facturas, y el registro de errores muestra un pico en la pantalla de pagos. La persona de turno cambia una línea del manifiesto para que invoices apunte a la versión anterior. Las sesiones nuevas reciben el remoto anterior poco después. El host y los demás remotos nunca estuvieron involucrados.

Confusión frecuente

Muchos equipos asumen que el rollback siempre está disponible. Hay que prepararlo. El build anterior debe seguir existiendo en el almacenamiento, lo que implica versionar y conservar los artefactos, y nunca sobrescribirlos en el mismo lugar. El equipo debe haber practicado el procedimiento. Y el cambio tiene que ser reversible desde el principio.

Ese último punto es la trampa habitual. Si el frontend nuevo necesita un campo nuevo de la API, o si con el release corrió una migración de base de datos, restaurar solo el frontend anterior puede dejarlo hablando con un backend que no entiende. Publicar primero los cambios de API compatibles hacia atrás, y después el frontend, mantiene abierto el camino de vuelta. La guía de migración lo incorpora en cada paso.

Términos relacionados

• Despliegue blue-green
• Canary release (despliegue canario)
• Feature flag
• Remote entry y manifiesto