¿Cómo administra las bases de datos durante el desarrollo?

Question

Mi equipo de desarrollo de cuatro personas se ha enfrentado a este problema desde hace un tiempo:

A veces necesitamos trabajar con el mismo conjunto de datos. Entonces, mientras nos desarrollamos en nuestras computadoras locales, la base de datos de desarrollo está conectada de forma remota.

Sin embargo, a veces necesitamos ejecutar operaciones en el db que pisa los datos de otros desarrolladores, es decir, rompemos las asociaciones. Para esto, un DB local sería agradable.

¿Existe una mejor práctica para solucionar este dilema? ¿Hay algo así como una herramienta "SCM for data"?

De una manera extraña, sería útil mantener un archivo de texto de SQL insertar/eliminar/actualizar consultas en el git repo, pero creo que esto podría ser muy lento muy rápidamente.

¿Cómo pueden lidiar con esto?

Answer 1

Puede que mi pregunta How Do You Build Your Database From Source Control le sea útil.

Fundamentalmente, la gestión eficaz de los recursos compartidos (como una base de datos) es difícil. Es difícil porque requiere equilibrar las necesidades de varias personas, incluidos otros desarrolladores, evaluadores, administradores de proyectos, etc.

A menudo, es más eficaz ofrecer a los desarrolladores individuales su propio entorno de espacio aislado en el que pueden realizar pruebas de desarrollo y unidades sin afectar a otros desarrolladores o probadores. Sin embargo, esto no es una panacea, porque ahora debe proporcionar un mecanismo para mantener estos múltiples entornos separados sincronizados entre sí a lo largo del tiempo. Debe asegurarse de que los desarrolladores tengan una forma razonable de detectar los cambios (tanto datos, esquemas y códigos). Esto no es necesariamente más fácil. Una buena práctica de SCM puede ayudar, pero aún requiere un nivel considerable de cooperación y coordinación para llevarlo a cabo. No solo eso, sino que el hecho de proporcionar a cada desarrollador su propia copia de un entorno completo puede generar costos de almacenamiento y recursos DBA adicionales para ayudar en la administración y supervisión de esos entornos.

Aquí están algunas ideas para que usted considere:

1. Crear una compartida, pública "entorno de pizarra" (que podría ser electrónico) donde los desarrolladores pueden ver fácilmente qué entornos están disponibles y que está utilizando.
2. Identifica un individuo o grupo para poseer recursos de base de datos. Son responsables de realizar un seguimiento de los entornos y ayudar a resolver las necesidades conflictivas de diferentes grupos (desarrolladores, probadores, etc.).
3. Si el tiempo y los presupuestos lo permiten, considere crear entornos de recinto de seguridad para todos sus desarrolladores.
4. Si aún no lo hace, considere separar las "áreas de juego" del desarrollador, de sus entornos de prueba de integración, prueba y aceptación.
5. Asegúrese de que la versión controle los objetos de base de datos críticos, especialmente aquellos que cambian a menudo como desencadenantes, procedimientos almacenados y vistas. No desea perder trabajo si alguien sobrescribe los cambios de otra persona.

Answer 2

En el pasado, he tratado esto de varias maneras.

Uno es el repositorio de secuencias de comandos SQL que crea y rellena la base de datos. No es una mala opción y puede mantener todo sincronizado (incluso si no está utilizando este método, debe mantener estos scripts para que su DB esté en control de código fuente).

El otro (que prefiero) tenía una única instancia de una base de datos de desarrollo "limpia" en el servidor que nadie se conectó. Cuando los desarrolladores necesitaban actualizar sus bases de datos de desarrollo, ejecutaban un paquete de SSIS que copiaba la base de datos "limpia" en su copia de desarrollo. Luego podríamos modificar nuestras bases de datos de desarrollo según sea necesario sin pisar los pies de otros desarrolladores.

Answer 3

Tenemos una herramienta de mantenimiento de base de datos que utilizamos que crea/actualiza nuestras tablas y nuestros procesos. tenemos un servidor que tiene una base de datos actualizada poblada con datos.

mantenemos las bases de datos locales con las que podemos jugar, pero cuando tenemos que volver a la "línea base" obtenemos una copia de seguridad del "maestro" del servidor y lo restauramos localmente.

si/cuando agregamos columnas/tablas/procs, actualizamos la herramienta dbMaintenance que se mantiene en control de fuente.

a veces, es un dolor, pero funciona razonablemente bien.

Answer 4

Si usa un ORM como nHibernate, cree un script que genere ambos el esquema & los datos en la base de datos de desarrollo LOCAL de sus desarrolladores.

Mejore ese script durante el desarrollo para incluir datos típicos.

Pruebe en una base de datos provisional antes de la implementación.

Repetimos la base de datos de producción a la base de datos UAT para los usuarios finales. Esa base de datos no es accesible por los desarrolladores.

Toma menos de unos pocos segundos para soltar todas las tablas, crearlas de nuevo e inyectar datos de prueba.

Si está utilizando un ORM que genera el esquema, no tiene que mantener el script de creación.

Answer 5

Usamos bases de datos de desarrolladores locales y una única base de datos maestra para las pruebas de integración. Almacenamos scripts de creación en SCM.Un desarrollador es responsable de actualizar los scripts SQL basados ​​en el esquema "maestro dorado". Un desarrollador puede realizar los cambios necesarios a su base de datos local, rellenando según sea necesario a partir de los datos en la base de datos de integración, utilizando un proceso de importación o generando datos utilizando una herramienta (Red Gate Data Generator, en nuestro caso). Si es necesario, los desarrolladores borran su copia local y pueden actualizar desde el script de creación y los datos de integración según sea necesario. Normalmente, las bases de datos solo se utilizan para las pruebas de integración y las falsificamos para las pruebas unitarias, por lo que se minimiza la cantidad de trabajo que mantiene sincronizadas las cosas.

Answer 6

Anteriormente, trabajé en un producto relacionado con el almacén de datos y diseñado para instalarse en los sitios del cliente si así lo deseaba. En consecuencia, el software sabía cómo realizar la "instalación" (principalmente la creación del esquema de base de datos requerido y la población de datos estáticos como códigos de moneda/país, etc.).

Como teníamos esta información en el código en sí, y como teníamos adaptadores de SQL conectables, era trivial conseguir que este código funcionara con una base de datos en memoria (utilizamos HSQL). En consecuencia, hicimos la mayor parte de nuestro trabajo de desarrollo y pruebas de rendimiento reales frente a servidores locales "reales" (Oracle o SQL Server), pero todas las pruebas unitarias y otras tareas automatizadas frente a DBs en memoria específicas del proceso.

Fuimos muy afortunados a este respecto de que si hubo un cambio en los datos estáticos centralizados, necesitábamos incluirlo en la parte de actualización de las instrucciones de instalación, por lo que de forma predeterminada se almacenó en el repositorio SCM, desprotegido por los desarrolladores e instalado como parte de su flujo de trabajo normal. En la reflexión, esto es muy similar a la idea propuesta de la lista de cambios de la base de datos, excepto un poco más formalizada y con una capa de abstracción específica de dominio a su alrededor.

Este esquema funcionó muy bien, porque Cualquiera podría construir una base de datos totalmente operativa con datos estáticos actualizados en unos pocos minutos, sin pisar los pies de nadie. No podría decir si vale la pena si no necesita la funcionalidad de instalación/actualización, pero lo consideraría de todos modos porque hizo que la dependencia de la base de datos fuera completamente indolora.

Answer 7

¿Qué pasa con este enfoque:

Mantener un acuerdo de recompra por separado para un "db limpia". El repositorio será un archivo sql con table crea/inserts, etc.

Usando Rails (estoy seguro que podría ser adaptado para cualquier repositorio git), mantenga el "clean db" como un submódulo dentro de la aplicación. Escriba un script (tarea de rake, tal vez) que consulte un DB de desarrollo local con las sentencias de SQL.

Para limpiar su base de datos local (y reemplazar con nuevos datos):

git submodule init 
git submodule update 

continuación

rake dev_db:update ......... (or something like that!) 

Answer 8

que he hecho una de dos cosas. En ambos casos, los desarrolladores que trabajan con código que podría entrar en conflicto con otros ejecutan su propia base de datos localmente o obtienen una instancia separada en el servidor de base de datos de desarrollo.

• Similar a lo que @tvanfosson recomendado, se mantiene un conjunto de secuencias de comandos SQL que puede construir la base de datos desde cero, o

• En una, regularmente bien definido, todas las bases de datos para desarrolladores se sobrescriben con una copia de los datos de producción, o con una copia reducida de la producción, según el tipo de datos que estamos usando.

Answer 9

Le recomiendo que eche un vistazo a las opiniones de Scott Allen sobre este asunto. Escribió una serie de blogs que, en mi opinión, son excelentes. Three Rules for Database Work, The Baseline, Change scripts, Views, stored procs etc, Branching and Merging.

Uso estas pautas más o menos, con cambios personales y funcionan.

Answer 10

Estoy de acuerdo con todo lo que LBushkin ha dicho en su respuesta. Si está usando SQL Server, tenemos una solución aquí en Red Gate que debería permitirle compartir fácilmente los cambios entre múltiples entornos de desarrollo.

http://www.red-gate.com/products/sql_source_control/index.htm

Si existe la preocupación de almacenamiento que hacen que sea difícil para su DBA para permitir múltiples entornos de desarrollo, Puerta Roja tiene una solución para esto.Con la tecnología HyperBac de Red Gate puede crear bases de datos virtuales para cada desarrollador. Estos parecen ser exactamente los mismos que la base de datos común, pero en el fondo, los datos comunes se comparten entre las diferentes bases de datos. Esto permite a los desarrolladores tener sus propias bases de datos sin ocupar una cantidad poco práctica de espacio de almacenamiento en su SQL Server.