Una migración sin vuelta atrás no es un plan; es una apuesta. Y en producción, apostar es un lujo que rara vez sale gratis.
Lo aprendà de la peor manera: ejecutando un cambio en los datos que salió mal a mitad, en un sistema donde no habÃa forma de deshacerlo. La migración modificó parte de los registros, falló, y me dejó con una base de datos a medio camino entre el estado antiguo y el nuevo: ni uno ni otro, y sin un botón para volver. Las horas siguientes no las dediqué a arreglar el problema original, sino a reconstruir a mano lo que un simple « deshacer » habrÃa resuelto en segundos.
Desde entonces, no ejecuto un cambio irreversible sin preguntarme primero cómo volverÃa atrás si saliera mal. A veces la respuesta es una copia de seguridad probada, tomada justo antes. A veces es diseñar la migración por pasos, cada uno reversible, en vez de un gran salto. A veces es aplicar el cambio primero en una copia y observarlo antes de tocar lo real. La forma cambia; la pregunta no: ¿cómo salgo de aquà si esto falla?
Porque va a fallar alguna vez. No cada migración, pero sà las suficientes como para que « no puede salir mal » sea una frase peligrosa. Los sistemas que sobreviven no son los que nunca se equivocan; son los que pueden retroceder cuando se equivocan.
El mejor momento para pensar en la vuelta atrás es antes de empezar, cuando todo está tranquilo y no te hace falta. El peor es en mitad del incidente, cuando lo único que quieres es volver al estado de hace cinco minutos y descubres que no dejaste ningún camino de vuelta.
– Serguey Shinder
