Reversión (Rollback) en desarrollo: qué es, métodos y cómo funciona

Qué es la reversión y el rollback en desarrollo

Reversión (rollback) es una operación que devuelve el sistema a un estado estable anterior. En el contexto del desarrollo, esto puede significar deshacer un commit en Git, revertir una transacción en la base de datos o volver a una versión anterior de una aplicación en el servidor. El término proviene del inglés “rollback” y está firmemente establecido en el vocabulario de los desarrolladores de todas las plataformas.

La necesidad de una reversión surge cuando un nuevo cambio rompe la funcionalidad, causa errores o no pasa los controles de calidad. En un proceso de desarrollo bien organizado, la reversión no es una señal de fracaso, sino un procedimiento estándar integrado en el flujo de trabajo. Cuanto más rápido pueda un equipo revertir un cambio problemático, menor será el impacto del error en los usuarios.

Diferentes herramientas ofrecen diferentes mecanismos de reversión: Git ofrece una elección entre revert seguro y reset destructivo, las bases de datos admiten rollback transaccional y los sistemas CI/CD pueden cambiar el tráfico entre versiones. La elección del enfoque depende del contexto y los requisitos de conservación del historial de cambios.

Git revert vs git reset: cuál es la diferencia

Git revert es un método seguro de reversión que crea un nuevo commit que deshace los cambios del anterior. El historial permanece lineal y todos los commits antiguos se conservan. Esta es la única opción correcta para revertir en una rama compartida en la que trabajan varios desarrolladores. Git revert no elimina el historial — añade el hecho de la reversión como un nuevo cambio.

Git reset mueve el puntero de la rama actual a un commit específico, descartando todos los cambios posteriores. Dependiendo de la bandera — soft, mixed o hard — reset maneja el directorio de trabajo y el índice de manera diferente. El modo hard elimina completamente los cambios del historial, lo que lo hace peligroso para ramas compartidas y adecuado solo para trabajo local.

Cuándo usar revert

Revert se usa en ramas compartidas: main, develop, release. Preserva el historial y permite que otros desarrolladores entiendan que un cambio fue deshecho. Después de revert, puedes hacer git pull de forma segura — el sistema no generará conflictos relacionados con el historial reescrito. En el trabajo en equipo, revert es el estándar por defecto.

# Deshacer el último commit creando un nuevo commit
git revert HEAD

# Deshacer un commit específico por hash
git revert a1b2c3d

Cuándo usar reset

Reset es apropiado en una rama local donde aún no has publicado cambios. Si estabas experimentando y quieres limpiar completamente el historial — reset hard lo hará. En una rama local, puedes usar reset mixed para deshacer commits pero mantener los cambios en el directorio de trabajo para volver a hacer commit.

# Deshacer el último commit, mantener cambios en el directorio de trabajo
git reset HEAD~1

# Deshacer completamente — los cambios se eliminan permanentemente
git reset --hard HEAD~2

Rollback en bases de datos: transacciones y ACID

Rollback de transacción es una operación que deshace todos los cambios realizados dentro de la transacción actual y devuelve la base de datos al estado en que se encontraba al inicio de la transacción. Esto garantiza la atomicidad — uno de los cuatro principios ACID (Atomicity, Consistency, Isolation, Durability). Si ocurre un error en cualquier etapa de la transacción, se ejecuta un rollback y los datos vuelven a su estado original.

El mecanismo de rollback se implementa a través del registro de escritura anticipada (Write-Ahead Log, WAL). Antes de modificar una página de datos, el SGBD escribe los valores antiguos y nuevos en el registro. Durante el rollback, el sistema lee el registro y restaura los valores originales de todas las páginas modificadas. Esto garantiza que incluso en caso de fallo de alimentación, la transacción pueda deshacerse correctamente.

BEGIN TRANSACTION;

UPDATE accounts
SET balance = balance - 100
WHERE id = 1;

-- Rollback on error
ROLLBACK;

Savepoint: reversión parcial

En transacciones largas, es conveniente usar savepoints — puntos de guardado intermedios a los que se puede retroceder sin completar toda la transacción. Esto permite manejar errores dentro de una operación compleja sin perder el progreso en otras partes. Los savepoints son compatibles con la mayoría de los SGBD relacionales: PostgreSQL, MySQL, Oracle.

SAVEPOINT sp1;

UPDATE orders SET status = 'cancelled'
WHERE id = 42;

ROLLBACK TO sp1;

Reversión en despliegue: estrategias y herramientas

Reversión de despliegue es volver a una versión anterior de una aplicación en ejecución después de un despliegue fallido. Esta es una capacidad crítica para entornos de producción: el tiempo de recuperación (MTTR) afecta directamente al SLA y la experiencia del usuario. Las plataformas modernas ofrecen varias estrategias de reversión según la arquitectura y los requisitos de disponibilidad.

Blue-green deployment

Blue-green es una estrategia en la que dos entornos idénticos funcionan simultáneamente: blue (versión actual) y green (versión nueva). El tráfico se cambia a green después de un despliegue exitoso. Si la nueva versión funciona incorrectamente, el conmutador de tráfico vuelve a blue. La reversión se realiza al instante, sin necesidad de redespliegue — solo hay que cambiar la ruta.

Canary release con reversión automática

Canary deployment dirige una pequeña parte del tráfico a la nueva versión y monitorea métricas: tasa de errores, tiempo de respuesta, porcentaje de solicitudes exitosas. Si las métricas empeoran, el sistema revierte automáticamente el canary y dirige todo el tráfico a la versión estable. Kubernetes y las mallas de servicios (Istio, Linkerd) admiten esta estrategia de forma nativa.

apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 10
  strategy:
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

Ejemplos prácticos de reversión en desarrollo

Examinemos tres escenarios típicos en los que un desarrollador necesita revertir cambios. Cada escenario requiere su propio enfoque — desde un simple comando en la terminal hasta un procedimiento de varios pasos que involucra CI/CD.

Escenario 1: commit accidental en main

Has hecho push accidentalmente de un commit con un error a main. Tu tarea es revertir los cambios sin perder el historial para el equipo. Usa git revert para crear un commit de reversión y luego git push. Todos los miembros del equipo verán la reversión y podrán continuar trabajando sin conflictos. Este es el método más seguro y transparente.

git checkout main
git pull origin main
git revert HEAD
git push origin main

Escenario 2: migración de base de datos fallida

Una migración de base de datos falló y algunos datos están corruptos. Usa rollback transaccional en el script de migración y restaura desde la copia de seguridad para los cambios ya aplicados. En un sistema bien diseñado, cada migración está envuelta en una transacción — en caso de error, el SGBD realiza automáticamente un rollback.

Escenario 3: despliegue con error crítico

Después de desplegar una nueva versión, descubres que la autorización no funciona. Si usas blue-green, la reversión es cambiar el router de vuelta. Si es una actualización continua — el comando kubectl rollout undo devolverá la versión anterior. Idealmente, el proceso de reversión debería estar automatizado y no tomar más de un minuto.