database - ¿Cómo se gestionan las bases de datos durante el desarrollo?

version-control data-integrity (10)

Mi equipo de desarrollo de cuatro personas ha estado enfrentando este problema desde hace algún tiempo:

A veces necesitamos trabajar con el mismo conjunto de datos. Así que mientras desarrollamos en nuestras computadoras locales, la base de datos dev está conectada de forma remota.

Sin embargo, a veces necesitamos ejecutar operaciones en la base de datos que pisará los datos de otros desarrolladores, es decir, rompemos asociaciones. Para esto un db local estaría bien.

¿Hay una mejor práctica para solucionar este dilema? ¿Hay algo así como una herramienta de "SCM para datos"?

De manera extraña, sería útil mantener un archivo de texto de las consultas de inserción / eliminación / actualización de SQL en el repositorio de git, pero creo que esto podría ser muy lento muy rápidamente.

¿Cómo lidian ustedes con esto?

¿Qué pasa con este enfoque:

Mantener un repositorio separado para una "base de datos limpia". El repositorio será un archivo sql con tablas creadas / inserciones, etc.

Usando Rails (estoy seguro de que podría ser adaptado para cualquier repositorio de git), mantenga la "base de datos limpia" como un submódulo dentro de la aplicación. Escriba una secuencia de comandos (tarea de rake, tal vez) que consulta un db de desarrollo local con las sentencias de SQL.

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

git submodule init git submodule update

entonces

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

Anteriormente, trabajé en un producto que estaba relacionado con el almacén de datos y estaba diseñado para ser instalado en los sitios de los clientes, 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.).

Debido a que teníamos esta información en el código mismo, y porque teníamos adaptadores SQL conectables, fue trivial hacer que este código funcionara con una base de datos en memoria (usamos HSQL). En consecuencia, realizamos la mayor parte de nuestro trabajo de desarrollo real y las pruebas de rendimiento en servidores locales "reales" (Oracle o SQL Server), pero todas las pruebas de unidad y otras tareas automatizadas en base a DB en memoria específicos del proceso.

Fuimos muy afortunados a este respecto de que si hubiera un cambio en los datos estáticos centralizados, debíamos incluirlos en la parte de actualización de las instrucciones de instalación, por lo que, de forma predeterminada, se almacenó en el repositorio de SCM, verificada por los desarrolladores y Instalado como parte de su flujo de trabajo normal. Reflexionando, esto es muy similar a la idea de cambio de base de datos propuesta, excepto un poco más formalizada y con una capa de abstracción específica del dominio a su alrededor.

Este esquema funcionó muy bien, porque cualquiera podría construir una base de datos totalmente funcional con datos estáticos actualizados en unos pocos minutos, sin pisar los dedos de los demás. 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 totalmente indolora.

En el pasado, he tratado con esto de varias maneras.

Uno es el repositorio de SQL Script que crea y completa 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 base de datos esté en el control de fuente).

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

Estoy de acuerdo con todo lo que LBushkin ha dicho en su respuesta. Si está utilizando 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 existen problemas de almacenamiento que dificultan que su DBA permita múltiples entornos de desarrollo, Red Gate 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 iguales a los de una base de datos ordinaria, 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 impráctica de espacio de almacenamiento en su servidor SQL.

He hecho una de dos cosas. En ambos casos, los desarrolladores que trabajan en el código que puede entrar en conflicto con otros ejecutan su propia base de datos localmente u obtienen una instancia separada en el servidor de la base de datos dev.

De manera similar a lo que recomienda @tvanfosson, usted mantiene un conjunto de scripts SQL que pueden construir la base de datos desde cero, o
De forma bien definida y regular, todas las bases de datos de desarrolladores se sobrescriben con una copia de los datos de producción, o con una copia de la producción reducida o no identificada, según el tipo de datos que estemos utilizando.

Puede encontrar mi pregunta ¿Cómo construir su base de datos desde el control de código fuente útil.

Fundamentalmente, la administración efectiva 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, directores de proyectos, etc.

A menudo, es más efectivo dar 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 evaluadores. Sin embargo, esto no es una panacea, porque ahora tiene que 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 captar los demás cambios (datos, esquema y código). 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 lograrlo. No solo eso, sino que proporcionar a cada desarrollador su propia copia de un entorno completo puede introducir costos de almacenamiento y recursos adicionales de DBA para ayudar en la administración y supervisión de dichos entornos.

Aquí hay algunas ideas para que usted considere:

Cree una "pizarra de entorno" pública y compartida (podría ser electrónica) donde los desarrolladores puedan ver fácilmente qué entornos están disponibles y quién los está utilizando.
Identificar 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 los diferentes grupos (desarrolladores, evaluadores, etc.).
Si el tiempo y los presupuestos lo permiten, considere la creación de entornos de espacio aislado para todos sus desarrolladores.
Si aún no lo ha hecho, considere separar las "áreas de juego" de los desarrolladores de sus entornos de integración, prueba y prueba de aceptación.
Asegúrese de que la versión controle los objetos críticos de la base de datos, especialmente aquellos que cambian a menudo, como desencadenantes, procedimientos almacenados y vistas. No desea perder el trabajo si alguien sobrescribe los cambios de otra persona.

Si usa un ORM como nHibernate, cree un script que genere tanto el esquema como 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 del despliegue.

Nosotros replicamos 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.

Tarda menos de unos segundos en eliminar 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.

Te recomiendo que eches un vistazo a las opiniones de Scott Allen sobre este asunto. Escribió una serie de blogs que, en mi opinión, son excelentes. Tres reglas para el trabajo de base de datos , la línea de base , los guiones de cambio , las vistas, los procedimientos almacenados , etc. , la bifurcación y la fusión .

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

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

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

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

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

Utilizamos 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 cambios según sea necesario en 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 eliminan su copia local y pueden actualizarse desde el script de creación y los datos de integración según sea necesario. Por lo general, las bases de datos solo se usan para pruebas de integración y nos burlamos de ellas para realizar pruebas unitarias, por lo que se minimiza la cantidad de trabajo para mantener las cosas sincronizadas.