Administrar la migración de los cambios de base de datos de última hora a una base de datos compartida por una versión anterior de la misma aplicación

Question

Uno de mis objetivos es poder implementar una nueva versión de una aplicación web que se ejecuta lado a lado de la versión anterior. El problema es que todo comparte una base de datos. Una base de datos que en la nueva versión tiende a incluir refactorización significativa en las tablas de la base de datos. Me gustaría lanzar la nueva versión de la aplicación a los usuarios a lo largo del tiempo y poder volver a cambiarla a la versión anterior si es necesario.

Oren tenía una buena publicación configurando el problema, pero terminó con:

" Todavía nos encontramos en aguas turbias con respecto a la implementación en la producción con respecto a los cambios que afectan a todo el sistema, a saber, los cambios en la base de datos. Voy a discutir eso en la próxima entrega, tengo un poco fuera de control, me temo. & Quot;

El post de seguimiento nunca llegó ;-). ¿Cómo haría para gestionar la migración de los cambios de base de datos de última hora a una base de datos compartida por una versión anterior de la misma aplicación? ¿Cómo mantendrías sincronizados los datos?

Answer 1

Si la versión anterior tiene que mantenerse, los cambios simplemente no pueden romperse. Eso también ayuda cuando se implementa una nueva versión de una aplicación web. Si necesita revertir, realmente ayuda si puede dejar la base de datos como está.

Obviamente, esto conlleva importantes desventajas arquitectónicas, y es casi seguro que terminará con una base de datos que muestre su linaje, por así decirlo, pero los beneficios de la implementación suelen valer la pena, en mi experiencia.

Ayuda si tiene una colección sólida de pruebas de integración para cada versión antigua involucrada. Debería poder ejecutarlos en su base de datos de prueba migrada para cada versión que aún se considere como " posiblemente en vivo " - que bien puede ser " cada versión alguna vez " en algunos casos. Si puede controlar la implementación de forma estrictamente razonable, puede salirse con la posibilidad de tener solo compatibilidad para tres o cuatro versiones, en cuyo caso puede planificar la eliminación de tablas / columnas obsoletas, etc. si existe una necesidad real. Solo tenga en cuenta la complejidad de dicha planificación frente a los beneficios acumulados.

Answer 2

Lea el libro de Scott Ambler " Refactoring Databases " ;; tomar con una pizca de sal, pero hay bastantes buenas ideas ahí.

Los detalles de las soluciones disponibles dependen del DBMS que utilice. Sin embargo, puedes hacer cosas como:

• cree una nueva tabla (o varias tablas nuevas) para el nuevo diseño
• cree una vista con el nombre antiguo de la tabla que recopila datos de las nuevas tablas
• crear 'en lugar de' desencadenadores en la vista para actualizar las nuevas tablas en lugar de la vista

En algunas circunstancias, no necesita una nueva tabla, es posible que solo necesite desencadenadores.

Answer 3

Suponiendo que solo hay 2 versiones de tu cliente, solo conservaría una copia de los datos en las nuevas tablas.

Puede mantener el contrato entre las aplicaciones antiguas y nuevas detrás de las vistas en la parte superior de las nuevas tablas. Utilice antes / en lugar de desencadenadores para manejar escrituras en el " antiguo " vistas que realmente escriben en las nuevas tablas.

Mantiene 2 versiones de código y aún debe desarrollar su aplicación anterior, pero es inevitable.

De esta manera, no hay problemas de sincronización, efectivamente tendrías que lidiar con los conflictos de replicación entre " antiguo " y " nuevo " esquemas.

Más de 2 versiones se complican como se mencionó ...

Answer 4

Primero, me gustaría decir que este problema es muy difícil y es posible que no encuentres una respuesta completa.

Últimamente he estado involucrado en el mantenimiento de una línea heredada de aplicaciones comerciales, que pronto podría evolucionar a una nueva versión. El mantenimiento incluye la solución de errores, la optimización del código antiguo y las nuevas funciones, que a veces no se adaptan fácilmente a la arquitectura actual de la aplicación. El principal problema con nuestra aplicación es que estaba mal documentado, no hay rastro de cambios y básicamente somos el equipo de 5ta rotación que está trabajando en este proyecto (somos bastante nuevos en él).

Dejando los detalles externos en el lado (código, capas, etc.), intentaré explicar un poco cómo estamos administrando actualmente los cambios en la base de datos.

Tenemos en este momento dos reglas que estamos tratando de seguir:

1. Primero, es que el código antiguo (sql, procs almacenado, función, etc.) funciona tal como está y debe conservarse tal como está, sin modificar demasiado a menos que exista un caso (cambio de característica o error), y de Por supuesto, trate de documentarlo lo más posible (especialmente los problemas como: " WTF !, ¿por qué hizo eso en lugar de eso? ").

2. En segundo lugar, cada nueva característica que se presente debe usar las mejores prácticas conocidas en este momento y modificar la estructura de la base de datos anterior lo menos posible. Esto introduciría algunas opciones de refactorización de la base de datos, como el uso de vistas editables sobre la estructura anterior, la introducción de nuevas tablas de extensión para las ya existentes, la normalización de la estructura y el suministro de la estructura más antigua a través de las vistas, etc.

Además, estamos tratando de escribir tantas pruebas de unidad como podamos, siempre que los analistas de negocios trabajen codo a codo y documenten las reglas de negocios.

La refactorización de la base de datos es un campo muy complejo que debe responderse en una respuesta corta. Hay muchos libros que responden a todos sus problemas, one http://databaserefactoring.com/ que se apunta en uno de las respuestas .

Edición posterior: Esperemos que la segunda regla también responda al manejo de los cambios de ruptura.