¿Cómo gestionar y capturar cambios de bases de datos en varios desarrolladores?

Tenemos tres desarrolladores y un probador que trabajan contra la misma database. Cambiamos el esquema de la database con bastante frecuencia, y cada vez que lo hacemos tiende a tener un efecto dominó de dolores de cabeza para todos los demás.

¿Existen buenas prácticas para el desarrollo orientado a .NET contra MS SQL Server 2008 para gestionar esto? Estoy pensando en algo similar a Rails Migrations y cada desarrollador y tester tiene su propia database local. ¿O es eso excesivo? Al less sería bueno tener bases de datos de testing y desarrollo separadas, pero actualmente mantener manualmente dos bases de datos sincronizadas es probablemente peor que nuestra situación actual.

LiquiBase parece prometedor, ¿alguien lo ha utilizado con éxito en un entorno similar? ¿O hay mejores enfoques?

Estamos utilizando SQL Server 2008, VS 2008 y .NET 3.5 si eso es importante.

Tenemos scripts para generar DB desde cero y esto es lo que está sentado en el control de código fuente. Cada desarrollador (20 de ellos) está usando script para generar 2 bases de datos en sus estaciones de trabajo. Uno para "trabajo": testing manual con datos de muestra (hay una secuencia de commands para rellenar los datos de muestra). Otro DB está vacío y se usa en testings unitarias (transacción abierta – do unit test – roll back).

La testing unitaria es obligatoria en el entorno multiprocesador. También siempre creamos una database "antigua" y aplicamos cambios de esquema en ella. Cada desarrollador está cambiando el esquema al crear procedimientos de actualización (esta es la forma en que hemos reconstruido y actualizado listos al mismo time).

Para las testings de performance, tenemos "cargadores": código C # para simular usuarios y poblar millones de loggings durante la noche en las estaciones de trabajo de los desarrolladores.

No usamos una herramienta per se, pero mantenemos todo nuestro esquema bajo control de fuente y luego tenemos un script que actualizará o rebuildá el databse desde el código fuente. De esta forma, cuando se realizan cambios, todos podemos actualizar y mantenernos sincronizados. Esto simplemente se convierte en parte de la rutina diaria de la mañana, toma alnetworkingedor de 5 minutos al igual que la synchronization de su código. Esto no es perfecto, pero funciona para nosotros.

Ah, y se me olvidó agregar si realiza cambios en el esquema, también es responsable de escribir el script de migration, si es necesario. Esto tiende a ser necesario de todos modos cuando algo llega a la producción.

Espero que ayude.

La edición de la database de Visual Studio Team System (también conocida como "Data Dude") vale la pena examinarla. Puede rastrear los diffs de la database y generar scripts de los cambios para que pueda preparar un entorno de testing / testing antes del deployment, etc. Creo que sus características también están disponibles en la edición de Desarrollo (ver enlace anterior) y en VS 2010 serán más visibles. Eche un vistazo a esta publicación de blog: Primera experiencia con Visual Studio 2008 Database Edition, ¡me encanta!

Eso, junto con TFS, le da la capacidad de controlar las versiones de los files SQL y ejecutarlos en la database.

Estoy en el campamento de "una database de desarrollo".

A diferencia del código fuente de OO tradicional, la database a menudo va a tener tablas que soporten características de múltiples usuarios. Cuando varios desarrolladores van a hacer cambios similares, puede hacer que lo resuelvan con anticipación o intenten sincronizar dos scripts de compilation. El problema con las secuencias de commands y las migraciones de compilation es que la mayoría de las situaciones no son triviales. ¿Desea deshabilitar NULLs en la database? – debe decidir a qué datos se debe aplicar el valor pnetworkingeterminado y si los datos se deben completar desde otro lugar. ¿Necesita refactorizar para normalizar una tabla en dos? – debe decidir cómo asignar las keys. Y luego con dos usuarios haciendo un cambio en la misma table …

Eso no quiere decir que no deba estar bajo el control de la fuente, porque debería.

En última instancia, a medida que tenga más desarrolladores y más canales de comunicación, querrá que sus cambios en la database pasen por un DBA de desarrollo, esto permite que los cambios se coordinen y evite muchos problemas con los canales de comunicación en un equipo. canales en una estrella.

Además, si se limita a progtwigr contra una capa de services de database explícita como vistas y processs almacenados, los desarrolladores de sus aplicaciones estarán bien aislados contra cambios de database y refactorización.

Después de un cierto time de desarrollo, los cambios en la database se vuelven bastante manejables, ya que los cambios en el esquema subyacente de la tabla base son menores (aunque las vistas y los processs almacenados pueden permanecer volátiles).

Parece que necesitas una herramienta de diferencia de database para crear y almacenar los cambios de tu database …

Red Gate SQL Compare

Edición de la database de Visual Studio Team

Personalmente, creo que es mejor tener bases de datos separadas. Todo trabajar contra una database puede causar mucho dolor y perder time.

Por ejemplo, supongamos que estoy investigando un problema de performance y estoy ejecutando algunas testings comparativas para probar algunas optimizaciones en la database: la única forma en que puede hacerlo de manera confiable es si es coherente con sus testings. Si alguien más realiza un cambio en el DB a mitad de path, eso podría sesgar sus hallazgos.

Además, si estoy en el medio de algo y la database cambia sin que yo sepa que me causa errores / comportamiento inesperado, podría pasar x cantidad de time trabajando antes de descubrir que se debe a un cambio que alguien más ha hecho.

En cambio, creo que es mucho mejor tener sus propias bases de datos de desarrollo / testing, de las cuales cada uno puede responsabilizarse de la actualización. Luego, tenga un server de continuous integration que extraiga automáticamente el último código del control de origen y lo construya cada x horas.