Recuperar una versión y entender el fallo

Si una nueva receta sale mal, recuperar la anterior ayuda a continuar atendiendo. Pero no deshace los platos que ya se sirvieron. En software, volver a una versión conocida tampoco revierte automáticamente todos sus efectos.

La recuperación debe pensarse antes de activar. Hace falta conocer qué versión puede utilizarse, qué datos acepta y cómo comprobar que vuelve a atender correctamente. Conservar un paquete anterior es un comienzo; la compatibilidad determina si puede usarse.

Contener, observar y recuperar

Imaginemos una incidencia en nuestro pedido ficticio: una nueva versión cobra envío donde debía ser gratuito. Este recorrido ilustra decisiones, no una operación realizada:

1. Contener: detener nuevas activaciones y evaluar cómo limitar el efecto sobre los pedidos.
2. Conservar evidencia: identificar versión, configuración, periodo afectado y ejemplos del cálculo incorrecto.
3. Decidir el retorno: comprobar que la versión conocida puede operar con el estado actual.
4. Verificar: confirmar identidad y reglas después de recuperar.
5. Investigar: explicar la causa y añadir la comprobación que permita detectarla antes.

La contención y la recuperación pueden ser urgentes. Conservar evidencia no debe convertirse en una excusa para prolongar un impacto. La organización necesita responsables y un orden acordado según las consecuencias.

Código anterior, datos actuales

Nuestro cálculo inicial no guarda pedidos. En un sistema que sí los conserva, una versión nueva podría cambiar la estructura de los datos. Volver al programa anterior sin revisar esa transformación puede añadir otro fallo.

Tampoco se deshacen automáticamente un correo enviado, un pedido confirmado o un cobro. Esas consecuencias requieren una revisión propia. Restaurar datos desde una copia también puede eliminar cambios válidos posteriores; no debe tratarse como una acción equivalente a cambiar archivos.

En Git, una reversión puede registrar un cambio que compensa otro en el historial. Eso ayuda a rastrear decisiones sobre el código, pero no significa que el sistema en ejecución ya haya recuperado su estado. Todavía hace falta el recorrido de entrega y verificación.