Cómo revertir cambios en producción

Cuando algo se rompe en producción, saber hacer rollback es la diferencia entre un susto pasajero y un problema grave para tus usuarios. Aquí te muestro cómo revertir cambios en Lovable, restaurar tu base de datos en Supabase y volver a un commit específico en Vercel, paso a paso y con criterio.

¿Cómo revertir cambios directamente en Lovable?

Lovable guarda un historial completo de tus cambios usando Git commits por debajo, así que puedes volver a cualquier versión anterior con un par de clics.

Imagina que publicaste una actualización en tu app y notas que algo se rompió. Quizá ese UI de user impersonation que agregaste ya no lo necesitas y prefieres regresar a una versión limpia. La regla que repito en clases anteriores aplica también aquí: si no funciona, restaura y vuelve a intentar.

El flujo es simple:

• Abre el view history dentro de Lovable.
• Busca el cambio al que quieres regresar, por ejemplo, el momento en que agregaste la name generator page.
• Haz clic en restore this version en la esquina superior derecha.
• Espera unos segundos mientras Lovable recorre los commits y restaura el código.
• Pulsa update para publicar la versión restaurada en tu sitio en vivo [3:00].

Lo que verán tus usuarios será inmediatamente la versión anterior, sin el componente que estaba causando problemas.

¿Qué hace Lovable cuando restauras una versión? Recorre el historial de Git commits del proyecto y devuelve el código al estado exacto de ese punto. Después solo necesitas publicar para que el cambio llegue a producción.

¿Cómo restaurar la base de datos en Supabase?

Restaurar el front end no basta si también modificaste la base de datos. Lovable no siempre puede arreglar consultas SQL que se ejecutaron directamente en Supabase, y tarde o temprano tu base puede quedar desactualizada o rota.

Dentro de Supabase, ve a la pestaña database y baja hasta la sección de backups. Aquí encontrarás respaldos automáticos generados a lo largo del día según los cambios que hiciste [4:30].

Algunos detalles importantes sobre los backups:

• En el plan gratuito de Supabase los respaldos son limitados.
• En el plan más económico, alrededor de diez dólares al mes, los backups vienen incluidos con mayor frecuencia.
• Cada respaldo muestra la fecha y la hora, así puedes elegir el punto correcto al que volver.

Para revertir, presiona restore y luego confirm restore. Eso devuelve tu base al estado de ese respaldo.

¿Qué pasa si solo restauro en Lovable y no en Supabase? Solo regresas el front end. Si ejecutaste consultas SQL que dañaron datos o esquemas, esos cambios siguen vivos en Supabase y necesitas restaurar el respaldo desde ahí.

¿Cómo hacer rollback en Vercel a un commit específico?

Si desplegaste tu proyecto en Vercel, cada cambio en tu rama de staging genera un nuevo deployment. Vercel detecta automáticamente cuando haces un revert en Lovable y vuelve a desplegar esa versión.

Pero a veces quieres ir a un commit muy específico, no solo al último. Para eso:

1. Ve al repositorio de GitHub de tu proyecto.
2. Abre la pestaña de commits y revisa el historial completo del ciclo de vida del proyecto.
3. Identifica el commit exacto al que quieres volver, por ejemplo, el que agregó la name generator page.
4. Copia el SHA de ese commit.
5. En Vercel, crea un nuevo deployment y pega ese SHA [6:50].

Vercel buscará la rama y el commit, y lo desplegará tal cual estaba en ese momento. Puedes hacerlo primero en staging para confirmar que todo se ve bien antes de tocar main.

También tienes la opción de elegir directamente la rama desde la que quieres desplegar, sin necesidad de copiar un SHA. Y si prefieres trabajar manualmente, GitHub ofrece varias formas de revertir commits desde su propia interfaz.

¿Qué debes recordar al hacer rollback en producción?

La mayoría de los pánicos de despliegue se resuelven con dos acciones: restaurar y volver a publicar. Lovable te da el historial visual, Supabase te da los respaldos de base de datos, y Vercel te da el control granular sobre qué commit exacto está vivo.

Algunas buenas prácticas que vale la pena interiorizar:

• Siempre revisa si tu cambio tocó solo el front end o también la base de datos antes de decidir dónde restaurar.
• Usa staging como tu red de seguridad antes de tocar main.
• Anota mentalmente o en notas qué commits representan versiones estables, así sabes a cuál volver si algo se rompe.
• Considera invertir los diez dólares al mes en Supabase si tu proyecto ya tiene usuarios reales, los backups frecuentes lo justifican.

Y si llegas a un punto donde ejecutaste un SQL desastroso, no entres en pánico. Ese respaldo de hace unas horas en Supabase probablemente te salva el proyecto.

En la siguiente clase vamos a montar una status page para avisar a tus usuarios cuando la app esté caída. ¿Tú ya tienes un flujo de rollback definido para tus proyectos? Cuéntame en los comentarios cómo lo manejas.