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

Question

Tenemos tres desarrolladores y un probador que trabajan contra la misma base de datos. Cambiamos el esquema de la base de datos 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 base de datos local. ¿O es eso excesivo? Al menos sería bueno tener bases de datos de prueba 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 realmente importante.

Answer 1

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

Las pruebas unitarias son obligatorias en el entorno multiproveedor. También siempre creamos una base de datos "vieja" 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 tiempo).

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

Answer 2

No usamos una herramienta per se, pero mantenemos todos nuestros esquemas bajo control de código fuente y luego tenemos un script que actualizará o reconstruirá 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 alrededor de 5 minutos al igual que la sincronización 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 migración, si es necesario. Esto tiende a ser necesario de todos modos cuando algo llega a la producción.

Espero que ayude.

Answer 3

Suena como que necesita una herramienta de diferencias de base de datos para crear y almacenar los cambios de base de datos ...

Red Gate SQL Compare

Visual Studio Team Database Edition

Answer 4

Visual Studio Team System Database Edition (también conocido como "datos de tipo") vale Mirando hacia. Puede rastrear los diffs de la base de datos y generar scripts de los cambios para que pueda preparar un entorno de prueba/prueba antes del despliegue, 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 en el blog: First Experience with Visual Studio 2008 Database Edition, I love it!!!

Eso, junto con TFS, le da la capacidad de controlar las versiones de los archivos SQL y ejecutarlos en la base de datos.

Answer 5

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

Por ejemplo, supongamos que estoy investigando un problema de rendimiento y estoy realizando algunas pruebas comparativas para probar algunas optimizaciones en la base de datos; la única forma en que puede hacerlo de manera confiable es si es coherente con sus pruebas. Si alguien más hace un cambio en el DB a mitad de camino, eso podría sesgar sus hallazgos.

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

En cambio, creo que es mucho mejor tener sus propias bases de datos dev/prueba que cada uno puede ser responsable de la actualización. Luego, tenga un servidor de integración continua que extraiga automáticamente el último código del control de origen y lo construya cada x horas.

Answer 6

Un buen enlace a algunos buenos enlaces: http://www.codinghorror.com/blog/2008/02/get-your-database-under-version-control.html

Answer 7

estoy en el campo de "una base de datos de desarrollo".

A diferencia de código fuente orientado a objetos tradicionales, la base de datos es a menudo van a tener tablas de ayuda características de varios usuarios. Cuando varios desarrolladores van a hacer cambios similares, puede hacer que lo resuelvan con anticipación o intenten sincronizar dos scripts de compilación. El problema con las secuencias de comandos y las migraciones de compilación es que la mayoría de las situaciones no son triviales. ¿Desea deshabilitar NULLs en la base de datos? - debe decidir a qué datos se debe aplicar el valor predeterminado y si los datos se deben completar desde otro lugar. ¿Necesita refactorizar para normalizar una tabla en dos? - debe decidir cómo asignar las claves. Y luego con dos usuarios realizar un cambio en la misma mesa ...

eso no es decir que no debe estar bajo control de código fuente, ya que debería. En la medida en que tenga más desarrolladores y más canales de comunicación, querrá que sus cambios de base de datos pasen por un DBA de desarrollo; esto permite coordinar los cambios y evita muchos problemas con los canales de comunicación en un equipo. convierte los canales de comunicación en una estrella.

Además, si se limita la programación en contra de una capa de servicios de bases de datos explícita como vistas y procedimientos almacenados, los desarrolladores de aplicaciones van a estar bien aislado contra los cambios de base de datos y refactorización.

Después de un cierto tiempo en el desarrollo, los cambios de base de datos se convierten en muy manejable, ya que los cambios en el esquema de la tabla base subyacente son menores (aunque vistas y procedimientos almacenados pueden permanecer volátil).