Prueba y gestión de versiones de bases de datos frente a versiones de código

Question

A medida que desarrolla una aplicación, inevitablemente surgen cambios en la base de datos.El truco que encuentro es mantener la compilación de la base de datos en sintonía con el código.En el pasado, agregué un paso de compilación que ejecutaba scripts SQL en la base de datos de destino, pero eso es peligroso en la medida en que podría agregar inadvertidamente datos falsos o algo peor.

Mi pregunta es ¿cuáles son los consejos y trucos para mantener la base de datos al día con el código?¿Qué pasa cuando reviertes el código?¿Derivación?

Answer 1

Los números de versión incorporados en la base de datos son útiles.Tiene dos opciones: incrustar valores en una tabla (permite versionar varios elementos) que se pueden consultar o tener un objeto con un nombre explícito (como una tabla o algo así) que pueda probar.

Cuando se lanza a producción, ¿tiene un plan de reversión en caso de una catástrofe inesperada?Si es así, ¿es la aplicación de un script de reversión de esquema?Utilice su secuencia de comandos de reversión para revertir la base de datos a una versión de código anterior.

Answer 2

Debería poder crear su base de datos desde cero en un estado conocido.

Si bien poder hacerlo es útil (especialmente en las primeras etapas de un nuevo proyecto), muchas (¿la mayoría?) bases de datos rápidamente se volverán demasiado grandes para que eso sea posible.Además, si tiene BLOB, tendrá problemas para generar scripts SQL para toda su base de datos.

Definitivamente he estado interesado en algún tipo de sistema de control de versiones de bases de datos, pero aún no he encontrado nada.Entonces, en lugar de una solución, obtendrás mi voto.:-PAG

Answer 3

Realmente desea poder tener una máquina limpia, obtener la última versión del control de fuente, compilar en un solo paso y ejecutar todas las pruebas en un solo paso.Hacer esto rápido le permite producir un buen software más rápidamente.

Al igual que bibliotecas externas, la configuración de la base de datos también debe estar en control de código fuente.

Tenga en cuenta que no estoy diciendo que toda su base de datos activa contenido debe estar en el mismo control de fuente, lo suficiente para llegar a un estado limpio.(¡Sin embargo, haga una copia de seguridad del contenido de su base de datos!)

Answer 4

Defina sus objetos de esquema y sus datos de referencia en archivos de texto con versión controlada.Por ejemplo, puede definir el esquema en Esfuerzo de torsión formato y los datos en Unidad DB formato (ambos usan XML).Luego puede usar herramientas (nosotros escribimos las nuestras) para generar DDL y DML que lo llevarán de una versión de su aplicación a otra.Nuestra herramienta puede tomar como entrada (a) los archivos XML de datos y esquemas de la versión anterior o (b) una base de datos existente, por lo que siempre podrá colocar una base de datos de cualquier estado en el estado correcto.

Answer 5

Me gusta la forma en que Django lo hace.Usted construye modelos y cuando ejecuta un syncdb, aplica los modelos que ha creado.Si agrega un modelo, solo necesita ejecutar syncdb nuevamente.Sería fácil hacer que su script de compilación lo haga cada vez que realice un impulso.

El problema surge cuando necesitas modificar una tabla que ya está hecha.No creo que syncdb se encargue de eso.Eso requeriría que ingresara y agregara manualmente la tabla y también agregara una propiedad al modelo.Probablemente desee versionar esa declaración de modificación.Sin embargo, los modelos siempre estarían bajo control de versiones, por lo que, si fuera necesario, podría ejecutar un esquema de base de datos en una nueva caja sin ejecutar los scripts SQL.Otro problema con esto es realizar un seguimiento de los datos estáticos que siempre desea en la base de datos.

Los scripts de migración de Rails también son bastante buenos.

Un sistema de control de versiones de bases de datos sería fantástico, pero realmente no conozco tal cosa.

Answer 6

Si bien poder hacerlo es útil (especialmente en las primeras etapas de un nuevo proyecto), muchas (¿la mayoría?) bases de datos rápidamente se volverán demasiado grandes para que eso sea posible.Además, si tiene BLOB, tendrá problemas para generar scripts SQL para toda su base de datos.

Las copias de seguridad y la compresión pueden ayudarle en ese sentido.Lo sentimos, no hay excusa para no poder obtener un buen conjunto de datos con los que desarrollar.Incluso si es sólo un subconjunto.

Answer 7

Ponga los desarrollos de su base de datos bajo control de versiones.Recomiendo echar un vistazo al diseñador neXtep:http://www.nextep-softwares.com/wiki

Es un producto GPL gratuito que ofrece un enfoque completamente nuevo para el desarrollo y la implementación de bases de datos al conectar la información de la versión con un motor de generación de SQL que podría calcular automáticamente cualquier script de actualización que necesite para actualizar cualquier versión de su base de datos a otra.Cualquier base de datos existente podría controlarse en versión mediante una sincronización inversa.

Actualmente es compatible con Oracle, MySql y PostgreSql.El soporte para DB2 está en desarrollo.Es un entorno de desarrollo de bases de datos con todas las funciones en el que siempre se trabaja en elementos controlados por versión desde un repositorio.Puede publicar sus actualizaciones mediante una simple sincronización durante el desarrollo y puede generar entregas de bases de datos exportables que podrá ejecutar en cualquier base de datos específica a través de un instalador independiente que valida las versiones, realiza comprobaciones estructurales y aplica los scripts de actualización.

El IDE también le ofrece editores SQL, gestión de dependencias, soporte para componentes de modelos de bases de datos modulares, diagramas de modelos de datos, clientes SQL y mucho más.

Toda la documentación y los conceptos se pueden encontrar en la wiki.