¿Cómo maneja las implementaciones de cambio de base de datos?

Hemos estado discutiendo las técnicas de implementación de la base de datos hoy, habiendo tenido un par de fallas recientes en nuestro proceso actual y hemos visto situaciones en las que nos gustaría revertir una implementación, pero la versión anterior de la aplicación nunca se había probado con la nueva versión del base de datos.

Por un lado, hay implementaciones de estilo de migración, donde tiene una instrucción de versión hacia arriba y una instrucción de versión hacia abajo (ya sea que estén escritas en SQL o en el idioma de su aplicación) y su aplicación sabe a qué versión debe llegar.

Estos son simples, y como no vamos a retroceder a menudo, los desarrolladores están interesados ​​en lo simple. Sin embargo, existen riesgos cuando agrega un campo / tabla y ese campo se llena antes de retroceder. O peor, donde se sueltan datos que eran relevantes para la versión anterior.

Por otro lado, podemos considerar un enfoque de actualización, retroceso y retroceso donde el retroceso no es tan drástico como con las migraciones. Por ejemplo, la actualización puede agregar un campo no anulable; la reversión hace que sea anulable para que la aplicación anterior no le importe; rollforward rellena los campos nulos y hace que no sea anulable nuevamente.

Esto retiene datos pero es complicado tanto para codificar como para probar (lamentablemente, nuestras pruebas de integración automatizadas son prácticamente inexistentes y mientras corregimos eso, mientras tanto tenemos un problema).

¿Hay formas seguras de mitigar los problemas con estos? ¿Hay otras opciones que debería considerar? ¿Has tenido malas experiencias que te gustaría compartir y que luego me puedan ahorrar dolor?

Los cambios en la base de datos deben manejarse como todos los demás cambios e implementarse como scripts como parte de la implementación (y, por supuesto, guardarse en el control de origen). Dado que se implementan con el código para la misma versión de la aplicación, usted sabe exactamente lo que debe revertirse. Puede hacerse elegante y escribir un script para deshacer cada cambio en el momento en que escribe el script de la base de datos, pero si las reversiones no son comunes, es posible que no desee hacerlo. Si se llena una nueva columna, perderá datos si regresa a la base de datos original.

En SQL Server, puede tomar una instantánea justo antes de una implementación y luego volver a ella inmediatamente si la implementación falla. Esto supone que la implementación NO se produce cuando los usuarios están en el sistema (no desea perder sus cambios de datos). Esto es más útil durante una versión principal cuando es posible que deba desactivar todo el sistema temporalmente para realizar la actualización. O bien, puede tomar la instantánea y hacer una comparación de la base de datos entre la instantánea y la base de datos para ver las diferencias si necesita revertir. Una herramienta como SQLCompare puede incluso generar el código para volver a la estructura de la instantánea. No sé qué hay disponible para otras bases de datos.

Los cambios en la estructura de una base de datos deben ser automatizados / programados y probados utilizando un entorno de prueba. Los cambios manuales son demasiado riesgosos en un entorno de producción.

La única estrategia de reversión razonable (la que tiene la menor probabilidad de empeorar las cosas) es volver a una instantánea previa a la actualización. Si las cosas van a salir mal, sucederá lo suficientemente rápido como para que sea manejable volver a la instantánea o demasiado tarde para una reversión (el siguiente informe de fin de semana falla debido a problemas en la base de datos).

Los cambios se pueden hacer de forma incremental (como agregar un campo) y, por lo tanto, probarse en vivo con menos riesgo que cuando se realizan todos de una sola vez.

Con la planificación, puede realizar cambios en la base de datos para admitir varias versiones futuras, en lugar de tener que enfrentar el software y la actualización de la base de datos con cada versión.

Prepárese para estar en modo de emergencia los días posteriores a una actualización de la base de datos, tal como lo haría si fuera una actualización de software.

Resista la necesidad de parchear los problemas manualmente. Use su estrategia de contingencia (reversión, instantánea) y luego piense por qué las cosas salieron mal antes de intentar la actualización nuevamente.