asp.net - tools - sql server source control

¿Deberíamos tener una instancia de base de datos separada para cada desarrollador? (12)

¿Cuál es la mejor manera de desarrollar una aplicación basada en bases de datos? Podemos tener dos enfoques.

Una base de datos común para todos los desarrolladores.
Base de datos separada para todos los desarrolladores.

¿Cuáles son los pros y los contras de cada uno? ¿Y cuál es la mejor manera?

Edición: se supone que más de un desarrollador debe actualizar la base de datos y ya tenemos SqlExpress 2005 en cada máquina de desarrollador.

Edit: La mayoría de nosotros estamos sugiriendo una base de datos común. Sin embargo, si uno de los desarrolladores ha modificado el código y el esquema de la base de datos. No ha confirmado los cambios de código, pero los cambios de esquema han pasado a la base de datos común. ¿No será posible romper el código de otros desarrolladores?

¿Por qué demonios querrías una base de datos separada para todos los desarrolladores? Tenga una base de datos común para todos, de esa manera la estructura de la tabla es consistente y las declaraciones de SQL también lo son.

Ambos -

Me gusta una base de datos única en la que los cambios se prueban antes de comenzar a funcionar o ir a un entorno de prueba "formal". Este es el control de cordura de tu desarrollador; se mantiene actualizado con el sistema en vivo y se asegura de que siempre consideren los cambios de cada uno. La regla debería ser que los cambios no continúen aquí si pueden romper algo más.

Una base de datos por desarrollador es excelente (incluso esencial) cuando más de un desarrollador está realizando actualizaciones. Les permite toda la flexibilidad de desarrollo que desean sin romper las cosas para otros desarrolladores.

La clave es tener un proceso para mover los cambios de la base de datos desde el desarrollo hasta su sistema en vivo, y atenerse a su proceso.

Depende de tus ciclos de desarrollo, pruebas y mantenimiento. También en el tamaño y la ubicación del equipo de desarrollo (y, por supuesto, la organización). Si admite varias versiones de la base de datos, es posible que necesite incluso más entornos.

En el mundo real encontré el siguiente enfoque bastante satisfactorio:

Una única base de datos / aplicación central para fines de prueba, consigue que todos los cambios de varios desarrolladores se fusionen periódicamente
Copias locales para el desarrollo (por lo que puede soltar y volver a cargar toda la base de datos)
Los scripts de actualización se mantienen para cualquier cambio en los conjuntos de datos de esquema, auxiliares y de muestra.

Aquí hay algunos puntos adicionales:

Si dos desarrolladores (dos equipos) están trabajando en cambios que pueden afectarse entre sí, deben completar sus tareas de forma independiente y luego integrar / fusionar y probar. Para esto es mucho mejor tener entornos de desarrollo separados (a menos que tengan que trabajar juntos, en cuyo caso los considero parte del mismo equipo; aún así, pueden trabajar en sus propias copias de la base de datos y compartirlas si es necesario)

Si trabajan en los cambios que no se influyen entre sí, podrían funcionar en el servidor principal. O en sus propias copias locales de la base de datos.

Por lo tanto, desarrollar en la copia local tiene todos los beneficios sin riesgo en un caso general (cuando se admiten varias versiones del sistema y se mantienen los scripts de actualización de todos modos).

Aún así, es genial si puede compartir casos de prueba, por lo que la posibilidad de volcar / restaurar la base de datos de forma fácil y rápida es una gran ventaja.

EDITAR:
Todo lo anterior supone que es factible tener una copia en la máquina local de todo el sistema para fines de prueba (tamaño, rendimiento, licencias, etc.).

Hacemos ambas cosas:

Usamos la generación de código donde estoy y nuestra base de datos también se genera. Así que tenemos una instancia en cada cuadro de desarrollador donde se genera la base de datos. Luego usamos los scripts que se generan para aplicar los cambios a una base de datos de prueba central. Si eso va bien, aplicamos los cambios a la base de datos de producción durante un lanzamiento.

Lo bueno de este enfoque es que cuando nuestra "fuente de verdad" se registra en el control de fuente, todos los cambios en la base de datos se distribuyen automáticamente a los otros desarrolladores cuando se reajustan y regeneran. Funciona bien para nosotros.

La mejor manera es una base de datos única en el servidor Test / QA y una base de datos (probablemente en la computadora local del desarrollador) para cada desarrollador (por lo tanto, 10 desarrolladores trabajan con 10 + 1 bases de datos).

El mismo enfoque que para el desarrollo general: cada desarrollador tiene su propia copia del código fuente en la máquina local.

Además, el enfoque de base de datos múltiple simplifica el mantenimiento del esquema de base de datos en los sistemas de control de versiones. Estamos manteniendo los scripts de creación de bases de datos en SVN.

Estamos utilizando el enfoque, que se describe aquí: http://www.sqlaccessories.com/Howto/Version_Control.aspx

Los mayores problemas con los desarrolladores que tienen sus propias bases de datos son:

Primero, es poco probable que tenga el tamaño de la base de datos de producción real (si toma todas las bases de datos con las que necesitamos trabajar aquí, ocuparían varios cientos de gigabytes de espacio, no tengo eso disponible en mi máquina), esto hace que se escriba un código incorrecto que nunca funcionará en una base de datos grande por razones de rendimiento. El código SQL nunca debe escribirse contra un conjunto de datos significativamente más pequeño que el de prod.
En segundo lugar, los desarrolladores que usan su propia base de datos crean problemas cuando pasan mucho tiempo desarrollando algo y luego descubren solo después de fusionarse con una base de datos real que afecta a otra cosa. Encuentras esto mucho más rápido cuando compartes el entorno. Así que al final hay menos tiempo de desarrollo desperdiciado.
Los terceros desarrolladores que trabajan en cosas relacionadas deben saber acerca de los cambios que está realizando, esto afectará su cambio.

Cuando sabes que vas a afectar a los demás, creo que tiendes a ser más cuidadoso con lo que haces, lo cual es una ventaja en mi libro.

Ahora, el servidor de la base de datos compartida debe tener lo que llamamos una base de datos temporal, un lugar donde las personas pueden crear y probar cambios en la tabla, por lo que si están haciendo algo que podría ser necesario eliminar y volver a crear una tabla (¡lo que debería ser un caso raro!), pueden probar el proceso primero copiando la tabla a la base de datos de scratch y ejecutando su proceso allí y luego cambiando a la base de datos real cuando estén seguros de que funciona. O a menudo copiamos una tabla de copia de seguridad en la base de datos de borrador antes de probar un cambio en particular, por lo que podemos recrear fácilmente los datos antiguos en caso de que falle.

No veo ninguna ventaja en absoluto al usar bases de datos individuales.

Optaría por la solución # 1: Una base de datos común para todos los desarrolladores.

Pros

Menos costoso para la infraestructura;
Solo es necesario un volcado cuando llega el momento de actualizar la base de datos de desarrollo;
Todos se desarrollan con los mismos datos, por lo que representan el entorno de producción;

Contras

Si un desarrollador realiza una mala operación, esto podría afectar a una mayor cantidad de desarrolladores.

En cuanto a la solución # 2: una base de datos independiente para cada uno de los desarrolladores;

Pros

Esto podría ser útil para el desarrollo de nuevas características, cuando el desarrollo requiere aislamiento;

Contras

Más caro para la empresa (infraestructura, licencias ...);
Multiplicación de problemas causados por un ávido entorno de desarrollo de aislamiento (funciona en el entorno de devloper, no integrado);
Multiplicación de volcados por los DBA de la misma copia del entorno de producción.

Teniendo en cuenta lo anterior, recomendaría, dependiendo del tamaño de su empresa:

Una base de datos para el desarrollo;
Una base de datos para probar la integración;
Una base de datos para las pruebas de aceptación;
Uno para el desarrollo de nuevas características que quizás requiera pruebas de integración.

Si su empresa no requiere pruebas de integración, siga las pruebas de aceptación, este paso es crucial antes de comenzar la producción.

Pensé que lo tiraría por ahí, pero ¿por qué no permitir que cada desarrollador aloje su propia instancia de SQL Server Developer en sus escritorios y luego tenga un servidor compartido para cada uno de los otros entornos (desarrollo, control de calidad y producto)? Creo que incluso el MSDN básico que viene con Visual Studio Pro (si lo optas) incluye una licencia para el desarrollador de SQL Server.

El desarrollador puede trabajar en su escritorio sin afectar a los demás y luego puede hacer que muevan el código al siguiente entorno compartido como mejor le parezca (a voluntad, con compilaciones diarias / semanales, etc.).

EDITAR: Debo agregar que la instancia de escritorio permite a los desarrolladores hacer cosas que los DBA a menudo restringen en entornos compartidos. Esto incluye la creación de la base de datos, la copia de seguridad / restauración, el generador de perfiles, etc. Estas cosas no son esenciales, pero permiten que el desarrollador sea mucho más productivo al tiempo que reduce las demandas que hacen contra sus DBA.

El entorno compartido es completamente necesario para las pruebas; no recomendaría pasar del escritorio a la producción. Pero puede agregar mucho al permitir que los desarrolladores tengan un control del 100% sobre un entorno de base de datos determinado (incluido el aislamiento de otros) con un costo relativamente menor.

Respuesta simple:

Tenga una base de datos de desarrollo, y si los desarrolladores quieren la suya, pueden ejecutar su propia instancia en sus propias máquinas. Sólo asegúrese de probar / publicar en el compartido.

También es posible que desee ver bases de datos de refactorización . Además de analizar los cambios en la base de datos, incluye discusiones sobre cómo pasar del desarrollo a la producción de una manera que reduce el riesgo.

Uno por desarrollador más un servidor de integración y compilación continua para ejecutar pruebas de unidad e integración. Eso te da lo mejor de ambos mundos.

Hacer que todos los desarrolladores modifiquen una sola base de datos de desarrollo rápidamente se vuelve menos productivo una vez que la cantidad de cambios en la base de datos alcanza un cierto nivel porque obliga a un desarrollador a implementar cambios en la base de datos compartida antes de que esté listo para registrarse, lo que significa que otras partes del código la línea puede romperse innecesariamente.

Base de datos compartida

Mas simple
Menos casos de "Funciona en mi máquina".
Integración de fuerzas
Los problemas se encuentran rápidamente (fallan rápido)

Bases de datos individuales

Nunca afecte a otros desarrolladores, pero esto también es algo malo, en una integración continua

Usamos una base de datos de desarrollo compartida y funciona bien. Nuestro esquema rara vez cambia de una manera que lo hace incompatible hacia atrás, pero ocasionalmente se producirá un cambio de diseño antes de que empecemos a funcionar, y simplemente pedimos a los otros desarrolladores que se actualicen.

Tenemos servidores de aplicaciones de desarrollo (web) separados, pero comparten la misma base de datos. Nuestros desarrolladores tienen la opción de usar su propia base de datos, ya que saben cómo configurar esto, y lo harán en ocasiones, pero solo temporalmente. La norma, para nosotros, es compartir la base de datos.