¿Debería permitirse a los desarrolladores usar LocalDB frente a una instancia de "desarrollo"?

Al igual que la pregunta que se publicó aquí anteriormente sobre " ¿Deberían los desarrolladores poder consultar las bases de datos de producción? ", ¡Quería tener su opinión sobre otro tema particularmente molesto!

Muchas compañías evitan que los desarrolladores instalen SQL Server Express y similares en máquinas de desarrollo, promoviendo el uso de Servidores SQL de desarrollo centralizados.

Específicamente, esto se hace para garantizar:

• Consistencia a nivel de parche entre servidores de desarrollo y producción
  
• Capacidad para probar y validar cualquier parche en lo anterior
  
• Seguridad de datos; solo los datos en los servidores de desarrollo se utilizan para el desarrollo
  
• Recuperabilidad; los datos son recuperables y aún están respaldados
  
• Diferencias de colación que pueden causar problemas cuando se pasa a producción

Para mí, todos estos argumentos son particularmente inválidos, tal vez con la excepción de los parches; pero si una base de datos en una máquina local se usa exclusivamente para actividades de desarrollo, y no para pruebas, entonces el parche se probará cuando una aplicación progrese a través de Prueba / UAT, etc. a Producción.

La clasificación no parece ser una razón válida, ya que si esto fuera una preocupación para la base de datos, debería establecerse cuando se crea de todos modos. Solo SharePoint y SCCM tienen problemas al respecto hasta donde yo sé;)

Ahora, suponiendo que es SOLO para el desarrollo, y la base de datos no se "moverá" a producción y los únicos movimientos serían:

• Scripts que crearon la base de datos que se genera para su implementación en producción
• Las copias de seguridad de los sistemas de terceros de "producción" se restauran y truncan cuando sea apropiado para validación y desarrollo

¿Alguien puede ver algún problema? ¿Me estoy perdiendo de algo?

Supongo que una de las mayores preocupaciones sería la posibilidad de que las instancias de db locales no estén actualizadas, pero ese es un problema de administración de software, no una IMO de DBA one.

Si. Todos los desarrolladores deben tener una instancia local de SQL Server Y una instancia de servidor SQL compartida. Existen para diferentes propósitos. Ambos son necesarios.

¿Quizás su entorno actual se parece a esto?

Arriba, varios desarrolladores están creando cambios y los están implementando en una base de datos comunitaria de desarrolladores SQL. Esto es malo. Microsoft MVP Troy Hunt documenta algunos de los puntos débiles de este enfoque anticuado, aquí . Los principales son ...

1. Incapacidad para controlar adecuadamente la fuente. ¡GRANDE!
2. Incapacidad para ajustar el rendimiento sin derechos a nivel de servidor.
3. Incapacidad para experimentar sin afectar a los demás.

Este patrón causa conflicto de desarrollador. Un síntoma del conflicto es la expansión de la base de datos. Muchas bases de datos se crean cuando los desarrolladores buscan un espacio seguro y aislado para hacer su trabajo. Hay varias razones por las cuales la organización se aferra a este patrón. La primera es que no han invertido en un sistema de control de fuente adecuado . Otra es que simplemente han heredado este patrón de diseño y no pueden molestarse en cambiarlo. Microsoft ha estado marchando constantemente de este patrón hacia algo más como esto ...

En el diagrama anterior, cada desarrollador usa Visual Studio para escribir y guardar los cambios de su base de datos en una instancia local de SQL Server. Esos cambios locales se sincronizan en un sistema de control de fuente apropiado. Aquí cada desarrollador puede diseñar y experimentar en un entorno donde sus cambios no afectarán a nadie más hasta que se registre. Y en ese momento los conflictos se resolverán.

La base de datos local utilizada anteriormente podría ser LocalDB, Express o ediciones Developer. Simple-Talk hace un gran trabajo sopesando los pros y los contras de cada uno aquí . Hay una razón por la que Microsoft ha creado tantas opciones para las bases de datos de desarrollo local: LocalDB, Express, Developer ... ¡deberíamos usarlas!

Si necesita elegir, es difícil no argumentar que todos los desarrolladores tienen instalada una versión local de SQL Server Developer Edition. Es completamente gratuito y tiene paridad de características con la edición Enterprise. Permitirá que todo su equipo explore y diseñe dentro de toda la pila de Microsoft BI (SQL Server, SSIS, SSRS y SSAS) de manera segura.

Todavía podemos mantener la base de datos comunitaria, pero no debería ser para el desarrollo, debería ser para pruebas. Es un servidor donde la configuración a nivel del sistema está sincronizada con la producción. Hardware, SO, parches, etc.

Para mí, todos estos argumentos son particularmente inválidos

Okay. Pero no son para el resto de nosotros. ¿Por qué?

Consistencia a nivel de parche entre servidores de desarrollo y producción

el parche se probaría cuando una aplicación avanzara a través de Test

Los parches pueden solucionar problemas de estabilidad y corrupción de datos que de otro modo afectarían a los desarrolladores. Debe hacerse en máquinas de desarrollo independientemente.

Seguridad de datos; solo los datos en los servidores de desarrollo se utilizan para el desarrollo

Es útil separar "lo que debería ser" de "lo que es". Los desarrolladores terminan con datos confidenciales (no necesariamente PII, pero tampoco libres) en sus bases de datos. Sucede.

Recuperabilidad; los datos son recuperables y aún están respaldados

Súper importante

Diferencias de colación que pueden causar problemas cuando se pasa a producción

Solo SharePoint y SCCM tienen problemas en torno a esto

Cualquier cosa que use una tabla temporal tendrá este problema. Es extremadamente común. Nunca lo notas porque la mayoría de las personas optan por una recopilación estándar en primer lugar.

asumiendo que es SOLO para desarrollo, y la base de datos no se "moverá" a producción

¿Por qué asumiríamos eso? Las cosas a menudo van del desarrollo a la producción. ¿De qué otra manera se llena la producción por primera vez? Guiones puros? No necesariamente cuando la aplicación ha estado en preproducción durante algún tiempo.

Supongo que una de las mayores preocupaciones sería la posibilidad de que las instancias de db locales no estén actualizadas, pero ese es un problema de administración de software, no una IMO de DBA one.

Simplemente necesita emitir una declaración sobre lo que hace y no apoya y por qué.

LocalDB es una parte central de SSDT ahora e inevitable. Sin embargo, no es accesible de forma remota y no tiene un componente de programación (Express tiene problemas similares). Por lo tanto, generalmente no es compatible con los DBA en lo que respecta a las copias de seguridad, el mantenimiento y las verificaciones de integridad.

Pero consolidar a servidores de desarrollo centralizados todavía tiene sentido. Y ahora que Developer Edition es gratis, es aún más fácil justificar tener más.

Conceptualmente hablando, estás en el camino correcto. Para una organización que tiene un proceso de desarrollo maduro / Ciclo de vida de desarrollo de software (SDLC) que incluye control de código fuente, integración continua (CI), pruebas automatizadas y un grupo de TI que sabe cómo administrar diversos entornos y estaciones de trabajo para mantenerlos sincronizados en relación con el software y los niveles de parche, y los desarrolladores disciplinados que a) siguen el proceso, b) trabajan juntos yc) trabajan con TI, y luego tener 50 (o muchos) DB de desarrollo pueden funcionar:

• Sí, se pueden mantener software y niveles de parches consistentes en cualquier cantidad de estaciones de trabajo.
• Sí, cualquier "problema" puede surgir en las pruebas automatizadas y / o entornos de QA / UAT.
• Muchos dev DB no son tan fáciles de respaldar, pero tampoco imposibles. Si utiliza los perfiles móviles, los archivos de datos que se encuentran en la carpeta "Configuración local" de cada usuario de Windows podrían ser más fáciles de realizar. O, al menos, puede ser programado por TI para tomar archivos de todas las estaciones de trabajo de desarrollo, de forma similar a cómo se aseguraría de que todos estén correctamente parcheados.

PERO, como con casi todo lo demás, todo se reduce al contexto de la situación.

Una ventaja de tener bases de datos de desarrollo separadas es que se pueden trabajar varios proyectos simultáneamente sin impactar entre sí. (Por supuesto, este podría ser el único beneficio).

SIN EMBARGO, hay varios problemas a considerar:

• ¿Cuál es el tamaño del equipo y cuántas personas están trabajando en un proyecto en particular? Cuantas más personas tenga trabajando en un proyecto, más necesitará un servidor de desarrollo compartido / centralizado para que todos obtengan todos los cambios.

• En cuanto a la clasificación, SQL Server Express LocalDB tiene un matiz / restricción / limitación particularmente molesto:

  La clasificación de instancia para LocalDB se establece en SQL_Latin1_General_CP1_CI_AS y no se puede cambiar. Las colaciones de nivel de base de datos, nivel de columna y nivel de expresión son compatibles normalmente. Las bases de datos contenidas siguen las reglas de metadatos y colaciones tempdb definidas por las colaciones de bases de datos contenidas .

  La clasificación a nivel de instancia afecta no solo tempdb(es decir, la resolución de nombre de objeto con ámbito db y la clasificación predeterminada para tablas temporales pero no variables de tabla), sino también nombres de variables locales, nombres de cursor / nombres de parámetros y gotonombres de etiquetas. Por lo tanto, si sus servidores de producción tienen una clasificación a nivel de instancia de algo diferente SQL_Latin1_General_CP1_CI_AS, entonces LocalDB no es una buena opción.

• ¿Está utilizando las características de Enterprise Edition? Si solo se trata de reconstruir el índice ONLINE, entonces eso probablemente no importe. Pero si está utilizando algo como el Particionamiento de tabla, LocalDB no es una buena opción.

• Quizás el mayor problema es el aumento general del alcance de los problemas potenciales derivados de cualquier disparidad ambiental (nivel de sistema operativo, nivel de parche de software, configuración de instancia, configuración de base de datos, etc.) que podría conducir a un error. Si bien ya hemos aceptado (en un sentido general) que las pruebas automatizadas / QA / UAT encontrarían estos problemas, ¡eso no está garantizado ! Dado que los humanos cometen errores y que los humanos deben realizar todas las pruebas que verifiquen todas las rutas de código y todas las variaciones de datos (tipos, tamaño, etc.), es muy probable que cualquier número de escenarios noprobarse y que un error podría pasar y no ser notado hasta que un cliente lo encuentre en Producción. Esto sucede de todos modos, pero las posibilidades aumentan cuando se usa LocalDB para que cada desarrollador pueda tener su propia base de datos privada.

A lo que realmente se reduce es: ¿cuál es la razón de peso para usarlo en un entorno de equipo? En varios trabajos, siempre he trabajado en grupos donde había desarrolladores de aplicaciones e ingenieros de bases de datos, y aunque los desarrolladores de aplicaciones a veces se burlaban de un procedimiento almacenado solo para hacerlo más rápido (no suficientes DBEs de nosotros), los DBE hicieron la mayor parte del trabajo. Programación de bases de datos, incluida la comprobación (es decir, la corrección) de cualquier código que escribieron los desarrolladores de aplicaciones. El uso de LocalDB habría dificultado mucho más el trabajo en grupo. Y mientras usaba SQL Server Express (o incluso Developer Edition) para tener instancias personales en cada estación de trabajo de desarrollo a las que se podía acceder de forma remota, lo que facilitaba la colaboración, nunca fue realmente necesario tener ese nivel de aislamiento, ya que era raro que hacer que los cambios en la base de datos de un proyecto afecten negativamente a otro.

Por supuesto, aquellos de nosotros que éramos Ingenieros de bases de datos (DBE) tuvimos instalaciones locales de Express Edition y / o Developer Edition. Pero, eso era hacer pruebas que requerían más control sobre la configuración / seguridad a nivel de instancia, etc., de lo que podía permitirse en un servidor compartido. Y utilicé las instancias locales ocasionalmente, pero no con demasiada frecuencia. Pero para mis proyectos personales, me encanta LocalDB y lo uso con bastante frecuencia.