¿Una base de datos por desarrollador o no?

https://stackoverflow.com/questions/234580

04-07-2019
|

Pregunta

En un entorno de desarrollo corporativo que escribe principalmente software administrativo, ¿debería cada desarrollador usar su propia instancia de base de datos, o debería usar una instancia de base de datos central durante el desarrollo? ¿Cuáles son las ventajas y desventajas de cada enfoque? ¿Qué pasa con otros entornos y otros productos?

Solución

Si todos comparten la misma base de datos, es posible que tenga algunos problemas si alguien realiza un cambio de estructura en la base de datos y que el código no está " Sincronizado " con ella.

Recomiendo altamente un DB por desarrollador por la única razón por la que no quieres hacerlo " escribir " prueba para ver a alguien más anularte justo después. ¿Un simple ejemplo? Intenta mostrar producto para un sitio web. Todo funciona hasta que desaparezcan todos los productos. ¿Problema? Otro desarrollador decidió jugar con el " Activo " Bandera del producto para probar algo más. En casos así, una transacción podría no funcionar. Al final de la historia, dedicas tiempo a la depuración de acciones de otra persona.

Recomiendo encarecidamente replicar la base de datos provisional en la base de datos del desarrollador de vez en cuando para sincronizar la estructura (o, mejor aún, tener una herramienta para reconstruir una base de datos desde cero).

Por supuesto, requerimos scripts para los cambios en la base de datos y TODO está en un control de fuente.

Otros consejos

Los días en que los entornos de bases de datos deberían ser escasos han quedado atrás. Estoy escribiendo esta publicación en un XW9300 con discos SCSI de 5x15k en él. Esta máquina ejecutará un trabajo ETL sustancial en un período de tiempo bastante razonable y (a mediados de 2007) me costó alrededor de & # 163; 1.700 en eBay, incluidos los discos. Desde la perspectiva de un desarrollador, especialmente en proyectos centrados en bases de datos como el almacenamiento de datos, la línea entre un desarrollador y un DBA es bastante borrosa. Mientras escribo esto, estoy creando un marco de administración de particiones para un almacén de datos de SQL Server 2005.

Los desarrolladores deben tener una o más bases de datos de desarrollo propias por (IMO) por estos motivos:

Requiere que las personas mantengan los procedimientos almacenados, los scripts de parches y los archivos de definición de esquema en el control de origen. La aplicación de los parches se puede automatizar en gran medida. Incluso hay herramientas como Redgate SQL Compare Pro haz mucho del trabajo duro para esto.
Fomenta una arquitectura de aplicación que facilita la administración e implementación de la configuración, ya que las personas tienen que implementar en sus propias estaciones de trabajo. Muchas arrugas de implementación se solucionarán mucho antes de que lleguen a la producción o las personas se darán cuenta de que podrían haber salido mal.
Evita que los desarrolladores se tropiecen con el trabajo de los demás. En algo así como un almacén de datos en el que las personas trabajan con el código ETL, esto es una ganancia aún mayor.
Alienta un cierto grado de responsabilidad ya que los desarrolladores tienen que aprender la administración básica de la base de datos. Esto también elimina muchos de los requisitos para el personal de soporte operativo y algunos de los desarrolladores. Ops friction.
Si tiene su propia base de datos, no hay guardianes que obstruyan la experimentación u otro trabajo en ella. La política en torno a la gestión de 'servidores' desaparece ya que no hay 'servidores'. Esta es una ganancia de productividad en cualquier entorno con una burocracia importante.
Para pequeños volúmenes de datos, una PC común es lo suficientemente rápida para esto. Las ediciones o licencias de desarrollador están disponibles para la mayoría de los sistemas de administración de bases de datos, si no todos, y se ejecutarán en un sistema operativo de escritorio. Si está trabajando con Linux o Unix, este es un problema aún menor. Para volúmenes de datos más grandes, hasta e incluyendo la mayoría de las aplicaciones MIS, una estación de trabajo como HP XW9400 o Lenovo D10 puede equiparse con 5 discos de 15k por menos del costo de una gran cantidad de professional desarrollo herramientas . (Sí, sé que es una licencia dual, pero una licencia comercial para todas las plataformas para QT es de & # 163; 4000 por asiento). Una máquina como esta ejecutará un proceso ETL con 10 a 100 millones de filas más rápido de lo que piensas.
Facilita la configuración de más de un entorno para pruebas de humo o con fines de reconciliación. Como tiene un control completo sobre la máquina, tiene bastante margen para simular condiciones en un entorno de producción. Por ejemplo, una vez hice un emulador simple para Control-M simplemente compilando algunos de sus scripts de tiempo de ejecución. Cuando tenga este nivel de control y transparencia sobre el medio ambiente, puede producir un proceso de implementación probado con bastante solidez que haga mucho para eliminar las oportunidades de señalar con el dedo en la implementación de producción.

He visto pequeños equipos trabajando con 14 entornos, y tenía 7 activos en una estación de trabajo al mismo tiempo. En el trabajo pesado de la base de datos, como ETL, donde trabajas con tablas enteras, trabajar en un solo entorno de desarrollo es una receta para perder el tiempo o pasar tu tiempo caminando sobre cáscaras de huevo.

Además, puede usar licencias de desarrollo de un solo usuario para plataformas de bases de datos, lo que le puede ahorrar el costo de las estaciones de trabajo solo en la licencia de bases de datos. La mayoría de las licencias de desarrollador (Microsoft y OTN son un par de ejemplos con los que estoy familiarizado) le permitirán usar el sistema en una única estación de trabajo para un único desarrollador gratuito o por un precio nominal.

Por el contrario, los términos de licencia en servidores de desarrollo compartidos a menudo son algo turbios y he visto a los proveedores tratar de desanimar a los clientes para obtener licencias en servidores de desarrollo en más de una ocasión.

Cada uno de nuestros desarrolladores tiene una base de datos completamente funcional. Los cambios se guionan y la fuente se controla como cualquier otro código.

Idealmente, sí, cada desarrollador debería tener un " sandbox " entorno de desarrollo, para que puedan probar su código incluso antes de implementarlo en un entorno de prueba / almacenamiento compartido.

El entorno de cada desarrollador debe ejecutar pruebas con script que restablezcan la base de datos a un estado conocido. Esto es imposible de hacer en un entorno compartido.

El costo de dar a cada desarrollador su propia instancia es menor que el costo del caos resultante de múltiples desarrolladores que intentan probar cambios volátiles juntos en un entorno compartido.

Por otra parte, en muchas tiendas de TI, el sistema utiliza una infraestructura compleja, que involucra múltiples servidores de aplicaciones o múltiples nodos físicos. Entonces la economía cambia; es menos costoso para las personas cooperar y evitar pisar el trabajo de otras personas de lo que sería replicarlo para cada desarrollador. Especialmente cierto si integras costosos sistemas de terceros que no te otorgan licencias para múltiples entornos de desarrollo.

Entonces la respuesta es sí y no. :-) Dé a cada desarrollador su propio entorno si ese entorno se puede reproducir a bajo costo.

Mi recomendación es tener 2 niveles de entorno de desarrollo:

Cada desarrollador tiene su propio sistema de desarrollo personal, con su propio dp, servidores web, etc. Esto les permite codificar contra una configuración conocida, escribir pruebas automatizadas (nivel de sistema) que inicializan su base de datos y sistemas a un estado conocido, etc.

El entorno de integración de desarrollo es compartido por todos los desarrolladores y se utiliza para asegurarse de que todo funcione en conjunto como se esperaba antes de pasarlo a QA. El código se extrae del control de origen y se instala allí, y solo hay una única instancia de cualquier servidor (db o no).

Esta pregunta sugiere lo que un desarrollador necesita para hacer su trabajo. Ciertamente, debe proporcionarse una instancia de base de datos privada. Igualmente importante, me aseguraría de que la base de datos sea el mismo producto / versión que lo que pretende implementar. No se desarrolle en MySQL 6.x e implemente en MySQL 5.x. (¡Esto también se aplica a los servidores de aplicaciones y a los servidores web!)

Tener una base de datos de desarrollador no es necesariamente necesario, ya que necesita que esté alojado en su máquina local. Podría tener una máquina central de DBMS con todos los dev dbs ubicados en ella. Los profesionales son el administrador que desarrollas contra el DB objetivo. Menos gastos generales en las cajas de desarrollo, más espacio / potencia para IDE y servidores de aplicaciones. Los contras son el único punto de falla para todos los desarrolladores. (El servidor DBMS se cae, nadie puede trabajar). Falta de exposición del desarrollador para configurar y administrar el DBMS. Los desarrolladores no pueden experimentar tan fácilmente con los próximos lanzamientos de bases de datos o las opciones de bases de datos alternativas para resolver problemas difíciles.

Algunos de los pros pueden ser contras y viceversa, dependiendo de su organización y estructura. Tal vez no quieras que los desarrolladores administren el DBMS. Tal vez usted planea soportar diferentes plataformas de base de datos. La decisión se reduce a su organización, así como a sus opciones de plataforma de destino. Si planea apuntar a una variedad de combinaciones de DB / OS / servidor de aplicaciones, cada desarrollador no solo debe tener su propia base de datos, sino que debe funcionar en una combinación única. (MySQL / Tomcat / OSX para un DB2 / Jetty / Linux para otro Postegres / Geronimo / WinXP para un tercero, etc.) Si configura una tienda de tipo ASP (Application Service Provider) en un iSeries por otro lado, por supuesto Es probable que tenga un host central con todos los dbmses de desarrollo, pero cada desarrollador debe tener al menos una instancia de db separada para permitir cambios estructurales en el esquema.

Tengo una instancia de SQLServer Development Edition instalada localmente. Tenemos un servidor QA DB, así como múltiples servidores de producción. Todas las pruebas de desarrollo e integración se realizan utilizando mi servidor local (u otros servidores locales de desarrolladores). Los nuevos lanzamientos están en el servidor de control de calidad. Cada lanzamiento, después de la aceptación por parte del cliente, se pone en producción.

Como principalmente desarrollo web, uso el servidor web incluido con VS2008 para el desarrollo y la prueba local, luego publico la aplicación web en un servidor web de control de calidad alojado en una máquina virtual. Una vez aceptado por el cliente, se publica en uno de varios servidores web de producción diferentes, algunos virtuales, otros no, según la aplicación.

Mi departamento en mi empresa solo tiene entornos de desarrollo limitados, simplemente debido al costo de soporte y hardware. Tenemos un par de entornos que se basan en las actualizaciones nocturnas t-1 de la producción y algunas estáticas.

Idealmente, todos deberían tener el suyo, pero en muchos casos, esto no será práctico cuando se cumpla lo siguiente:

tiene una gran cantidad de desarrolladores que necesitan recursos (nuestro departamento tiene quizás 80)
cada desarrollador necesita múltiples recursos (normalmente uso 4-5 dbs diferentes cada día)
los datos actualizados son importantes (simplemente no puede actualizarlos lo suficientemente rápido)

En estos casos, se necesitan instancias compartidas y buena comunicación.

Una ventaja para una base de datos por desarrollador, cada desarrollador tiene una instantánea de sus propios datos en un "conocido" estado.

Me gusta la idea de usar una versión local cuando un desarrollador debe estar aislado: desarrollar un cambio de esquema, pruebas de rendimiento, configurar escenarios específicos, etc.

En otras ocasiones, use la versión compartida para asegurarse de que todo esté sincronizado entre sí.

Creo que hay un problema de terminología aquí. Ha pasado un tiempo desde que usé mi sombrero de DBA (golly gee, casi 10 años), por lo que alguien más puede intervenir y corregirme.

Creo que todos están de acuerdo en que cada desarrollador debe tener su propio conjunto de esquemas de espacio aislado.

En MySQL y Sybase / MS SQLServer, cada motor de base de datos puede admitir múltiples bases de datos. Cada base de datos es (normalmente) completamente independiente de la otra base de datos. Por lo tanto, puede tener una instancia de motor de base de datos y dar a cada desarrollador su espacio de base de datos para que haga lo que desee. el único problema es si los desarrolladores están usando tempdb (puede haber colisiones allí) (creo que tendrá que buscarlo). Solo tenga cuidado de que no se utilicen consultas de bases de datos cruzadas con nombres de bases de datos fijos.

En Oracle, la instancia del motor de la base de datos está vinculada a un conjunto de esquema particular. Si tiene varios desarrolladores en el mismo motor, todos apuntan a las mismas tablas. En este caso, sí, deberá ejecutar varias instancias.

Cada uno de nuestros desarrolladores tiene una base de datos local. Almacenamos el script de creación Y un volcado de los "datos estándar" en nuestro repo SVN. Tenemos un amplio conjunto de pruebas que deben pasar contra estos datos de prueba. También tenemos un '' sandbox '' base de datos que está disponible para que las personas ingresen los datos que desean compartir en los datos estándar. Esto funciona bien para nosotros y nos permite dejar que los desarrolladores modifiquen sus copias locales de datos para probar cosas, pero controlamos lo que se pasa a otros desarrolladores. También controlamos estrictamente los cambios de esquema, por lo que no encontramos los problemas que alguien más mencionó.

Realmente depende de la naturaleza de su aplicación. Si la suya es una arquitectura cliente-servidor en un entorno distribuido, es mejor tener una base de datos central que todos usen. Si el producto proporciona a los usuarios un entorno con instancias de bases de datos locales, puede usarlo. Es mejor si su desarrollo refleja el entorno del mundo real lo más cerca posible.

También depende de la etapa de desarrollo en la que se encuentre. Probablemente en las primeras etapas, no desee quedar empantanado por problemas de conectividad, red y entorno distribuido y solo quiera estar en funcionamiento. En tal caso, puede comenzar con un modelo de instancia de base de datos por usuario antes de cambiar al modelo central a medida que el producto alcanza cierto nivel de madurez.

En mi empresa, tendemos a copiar toda la base de datos cuando trabajamos en nuevas funciones no triviales. El razonamiento es que el espacio en el disco es barato, mientras que la pérdida accidental de datos (incluso si se trata de datos de prueba) no lo es.

He trabajado en ambos tipos de entornos de desarrollo. Personalmente, prefiero tener mi propio servidor de base de datos / aplicación. Sin embargo, puede haber algunas ventajas al usar una infraestructura compartida para el desarrollo.

El principal es que un entorno compartido se parece más a un escenario del mundo real: es más probable que descubra problemas con el bloqueo o las transacciones cuando todos los desarrolladores comparten una base de datos. Dar a cada desarrollador su propia base de datos puede llevar a que "funcione en mi base de datos" síndrome

Sin embargo, si necesita aplicar y probar cambios u optimizaciones de esquema, entonces puedo ver problemas en este tipo de configuración.

Tal vez una solución de compromiso funcionaría mejor: todos los desarrolladores comparten infraestructura, y si alguien necesita probar los cambios de esquema, crean su propia instancia de base de datos temporal (¿tal vez haya una sola para este propósito?) hasta que estén felices de comprometer el nuevo esquema al control de origen.

Tiene su esquema completo (y datos de prueba) en el control de origen, ¿verdad? ¿Cierto?

Me gusta la solución de compromiso (todos los desarrolladores comparten infraestructura, y si alguien necesita probar los cambios de esquema, crean su propia instancia de base de datos temporal (¿tal vez haya una que se quede allí para este propósito?) hasta que estén felices de cometer el nuevo esquema para el control de origen.)

Un DB por desarrollador. No hay duda. Pero el problema realmente es cómo hacer un script de bases de datos completas, " datos de control " ;, y cómo versionarlos. Mi solución está aquí: http://dbsourcetools.codeplex.com/ Que te diviertas. - Nathan.

Los esquemas de la base de datos deben mantenerse en el control de origen y los desarrolladores deben poseer los conjuntos de cambios registrados para el código y la db juntos. Antes de registrar, el desarrollador debe estar trabajando en su propia base de datos. Después del registro, una compilación automatizada (por ejemplo: en el registro, todas las noches, etc.) debe actualizar una base de datos integrada central, junto con las aplicaciones en sí.

A nivel de instancia de desarrollador, los datos cargados deben ser apropiados para pruebas de unidad, al menos. A nivel integrado, la base de datos compartida debe contener los datos también apropiados para las pruebas, pero no debe confiar en la replicación de la producción, esto es solo un sustituto de los datos de prueba administrados.

En mi experiencia, la única razón por la que los desarrolladores optan por una base de datos compartida es porque creen que desarrollar y ejecutar datos de producción recientes es de alguna manera "real" y significa que pueden poner menos esfuerzo en las pruebas. Prefieren pisar los otros dedos de los pies y soportar una base de datos compartida que se corrompe lentamente antes de la próxima actualización de producción que escribir y administrar las pruebas adecuadas. Es este tipo de práctica de administración la que le da al mundo de TI la mala reputación que tiene actualmente.

Yo sugeriría usar una instancia de la base de datos. No quieres que tu base de datos sea un objetivo móvil.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow