Implementación de bases de datos de SQL Server desde la prueba hasta la puesta en marcha

08-06-2019
|

Pregunta

Me pregunto cómo gestionan la implementación de una base de datos entre 2 servidores SQL, específicamente SQL Server 2005.Ahora, hay un desarrollo y uno vivo.Como esto debería ser parte de un script de compilación (lote estándar de Windows, incluso con la complejidad actual de esos scripts, podría cambiar a PowerShell más adelante), Enterprise Manager/Management Studio Express no cuentan.

¿Podrías simplemente copiar el archivo .mdf y adjuntarlo?Siempre tengo un poco de cuidado cuando trabajo con datos binarios, ya que esto parece ser un problema de compatibilidad (aunque el desarrollo y la versión en vivo deben ejecutar la misma versión del servidor en todo momento).

O, dada la falta de "EXPLICAR CREAR TABLA" en T-SQL, ¿hace algo que exporte una base de datos existente a SQL-Scripts que pueda ejecutar en el servidor de destino?En caso afirmativo, ¿existe alguna herramienta que pueda volcar automáticamente una base de datos determinada en consultas SQL y que se ejecute desde la línea de comandos?(Nuevamente, Enterprise Manager/Management Studio Express no cuentan).

Y, por último, dado el hecho de que la base de datos activa ya contiene datos, es posible que la implementación no implique crear todas las tablas, sino verificar la diferencia en la estructura y ALTER TABLE las activas, lo que también puede necesitar verificación/conversión de datos cuando cambian los campos existentes.

Ahora escucho muchas cosas maravillosas sobre el puerta roja Productos, pero para proyectos de hobby, el precio es un poco elevado.

Entonces, ¿qué estás usando para implementar automáticamente bases de datos de SQL Server desde Test to Live?

Solución

He empezado a codificar manualmente todas mis declaraciones DDL (crear/alterar/eliminar), agregarlas a mi .sln como archivos de texto y usar versiones normales (usando subversión, pero cualquier control de revisión debería funcionar).De esta manera, no solo obtengo el beneficio del control de versiones, sino que la actualización en vivo desde dev/stage es el mismo proceso para el código y la base de datos: las etiquetas, las ramas, etc., funcionan de todos modos.

De lo contrario, estoy de acuerdo en que Redgate es costoso si no tiene una empresa que lo compre por usted.Sin embargo, si puedes conseguir que una empresa te lo compre, ¡realmente vale la pena!

Otros consejos

Para mis proyectos alterno entre SQL Compare de REd Gate y el Asistente de publicación de bases de datos de Microsoft que puedes descargar gratis.aquí.

El asistente no es tan hábil como Comparación de SQL o Comparación de datos de SQL, pero funciona.Un problema es que los guiones que genera pueden necesitar cierta reorganización y/o edición para fluir de una sola vez.

Lo bueno es que puede mover su esquema y sus datos, lo cual no está nada mal para una herramienta gratuita.

No olvide la solución de Microsoft al problema: Edición de base de datos de Visual Studio 2008.Incluye herramientas para implementar cambios en bases de datos, producir diferencias entre bases de datos para cambios de esquema y/o datos, pruebas unitarias y generación de datos de prueba.

Es bastante caro pero usé la edición de prueba por un tiempo y pensé que era brillante.Hace que trabajar con la base de datos sea tan fácil como cualquier otro fragmento de código.

Al igual que Rob Allen, uso SQL Compare/Data Compare de Redgate.También utilizo el asistente de publicación de bases de datos de Microsoft.También tengo una aplicación de consola que escribí en C# que toma un script SQL y lo ejecuta en un servidor.De esta manera, puede ejecutar scripts grandes con comandos 'GO' desde una línea de comando o en un script por lotes.

Utilizo las bibliotecas Microsoft.SqlServer.BatchParser.dll y Microsoft.SqlServer.ConnectionInfo.dll en la aplicación de consola.

Trabajo de la misma manera que Karl, manteniendo todos mis scripts SQL para crear y modificar tablas en un archivo de texto que mantengo bajo control de código fuente.De hecho, para evitar el problema de tener que hacer que un script examine la base de datos activa para determinar qué ALTER ejecutar, normalmente trabajo así:

En la primera versión, coloco todo durante las pruebas en un script SQL y trato todas las tablas como CREATE.Esto significa que termino eliminando y leyendo tablas mucho durante las pruebas, pero eso no es gran cosa al principio del proyecto (ya que de todos modos estoy pirateando los datos que estoy usando en ese momento).
En todas las versiones posteriores, hago dos cosas:Creo un nuevo archivo de texto para contener los scripts SQL de actualización, que contienen solo los ALTER para esa versión.Y hago los cambios al original y también creo un script de base de datos nuevo.De esta manera, una actualización simplemente ejecuta el script de actualización, pero si tenemos que recrear la base de datos, no necesitamos ejecutar 100 scripts para llegar allí.
Dependiendo de cómo esté implementando los cambios de la base de datos, normalmente también colocaré una tabla de versiones en la base de datos que contiene la versión de la base de datos.Luego, en lugar de tomar decisiones humanas sobre qué scripts ejecutar, cualquier código que tenga ejecutando los scripts de creación/actualización utiliza la versión para determinar qué ejecutar.

Lo único que esto no servirá es si parte de lo que está pasando de la prueba a la producción son datos, pero si desea administrar la estructura y no pagar por un paquete de administración de base de datos agradable pero costoso, en realidad no es muy difícil.También descubrí que es una forma bastante buena de realizar un seguimiento mental de su base de datos.

Si una empresa lo compra, Toad de Quest Software tiene este tipo de funcionalidad de gestión integrada.Básicamente es una operación de dos clics para comparar dos esquemas y generar un script de sincronización de uno al otro.

Tienen ediciones para la mayoría de las bases de datos populares, incluido, por supuesto, Sql Server.

Estoy de acuerdo en que escribir un guión para todo es la mejor manera de hacerlo y es lo que defiendo en el trabajo.Debe crear un script para todo, desde la creación de bases de datos y objetos hasta completar las tablas de búsqueda.

Todo lo que hagas en la interfaz de usuario no se traducirá (especialmente los cambios...no tanto para las primeras implementaciones) y terminará requiriendo herramientas como las que ofrece Redgate.

Usando SMO/DMO, no es demasiado difícil generar un script de su esquema.Los datos son un poco más divertidos, pero aún factibles.

En general, adopto el enfoque "Script It", pero es posible que desees considerar algo como este:

Distinga entre desarrollo y puesta en escena, de modo que pueda desarrollar con un subconjunto de datos...Para esto, crearía una herramienta para simplemente extraer algunos datos de producción o generar datos falsos en lo que respecta a la seguridad.
Para el desarrollo del equipo, cada cambio en la base de datos deberá coordinarse entre los miembros de su equipo.Los cambios de esquema y datos se pueden mezclar, pero un único script debería habilitar una característica determinada.Una vez que todas sus funciones estén listas, las agrupa en un único archivo SQL y lo ejecuta para restaurar la producción.
Una vez que su preparación haya sido aceptada, ejecute el archivo SQL único nuevamente en la máquina de producción.

He utilizado las herramientas de Red Gate y son excelente herramientas, pero si no puede permitírselo, construir las herramientas y trabajar de esta manera no está muy lejos de lo ideal.

Estoy usando el mecanismo de migraciones de Subsonic, así que solo tengo una DLL con clases en orden secuencial que tienen 2 métodos, arriba y abajo.Hay un enlace de secuencia de comandos de integración/construcción continua en nant, para que pueda automatizar la actualización de mi base de datos.

No es lo mejor del mundo, pero es mejor que escribir DDL.

RedGate SQLComparar es un camino a seguir en mi opinión.Implementamos bases de datos con regularidad y desde que comencé a usar esa herramienta nunca he mirado atrás.Interfaz muy intuitiva y al final ahorra mucho tiempo.

La versión Pro también se encargará de las secuencias de comandos para la integración del control de fuente.

También mantengo scripts para todos mis objetos y datos.Para la implementación escribí esta utilidad gratuita: http://www.sqldart.com.Le permitirá reordenar sus archivos de script y ejecutará todo dentro de una transacción.

Estoy de acuerdo en mantener todo bajo control de código fuente y programar manualmente todos los cambios.Los cambios en el esquema de una versión única se guardan en un archivo de secuencia de comandos creado específicamente para esa versión.Todos los procesos, vistas, etc. almacenados deben ir en archivos individuales y tratarse como .cs o .aspx en lo que respecta al control de código fuente.Utilizo un script de PowerShell para generar un archivo .sql grande para actualizar la programación.

No me gusta automatizar la aplicación de cambios de esquema, como nuevas tablas, nuevas columnas, etc.Cuando hago una versión de producción, me gusta revisar el script de cambio comando por comando para asegurarme de que cada uno funcione como se espera.No hay nada peor que ejecutar un script de gran cambio en producción y obtener errores porque olvidó algún pequeño detalle que no se presentó en el desarrollo.

También aprendí que los índices deben tratarse como archivos de código y colocarse bajo control de código fuente.

Y definitivamente deberías tener más de 2 bases de datos: dev y live.Debería tener una base de datos de desarrollo que todos utilicen para las tareas diarias de desarrollo.Luego, una base de datos provisional que imita la producción y se utiliza para realizar las pruebas de integración.Luego, tal vez una copia reciente completa de la producción (restaurada a partir de una copia de seguridad completa), si es posible, de modo que su última ronda de pruebas de instalación vaya en contra de algo que sea lo más cercano posible a la realidad.

Hago toda la creación de mi base de datos como DDL y luego envuelvo ese DDL en una clase de mantenimiento de esquema.Puedo hacer varias cosas para crear el DDL en primer lugar, pero fundamentalmente hago todo el mantenimiento del esquema en código.Esto también significa que si uno necesita hacer cosas que no sean DDL y que no se correspondan bien con SQL, puede escribir lógica de procedimiento y ejecutarla entre grupos de DDL/DML.

Luego, mi base de datos tiene una tabla que define la versión actual para que uno pueda codificar un conjunto de pruebas relativamente sencillo:

¿Existe la base de datos?Si no, créelo.
¿Es la base de datos la versión actual?De lo contrario, ejecute los métodos, en secuencia, que actualicen el esquema (es posible que desee pedirle al usuario que confirme e, idealmente, que haga copias de seguridad en este punto).

Para una aplicación de un solo usuario, simplemente ejecuto esto en su lugar, para una aplicación web actualmente bloqueamos al usuario si las versiones no coinciden y tenemos una aplicación de mantenimiento de esquema independiente que ejecutamos.Para multiusuario dependerá del entorno particular.

¿La ventaja?Bueno, tengo un nivel muy alto de confianza en que el esquema de las aplicaciones que utilizan esta metodología es coherente en todas las instancias de esas aplicaciones.No es perfecto, hay problemas, pero funciona...

Hay algunos problemas cuando se desarrolla en un entorno de equipo, ¡pero eso es más o menos un hecho de todos modos!

Murph

Actualmente estoy trabajando lo mismo para ti.No solo implementa bases de datos de SQL Server desde la prueba hasta la puesta en marcha, sino que también incluye todo el proceso desde Local -> Integración -> Prueba -> Producción.Entonces, lo que puede hacerme fácilmente todos los días es que lo hago. Tarea NAnt con comparación de Red-Gate SQL.No trabajo para RedGate pero debo decir que es una buena elección.

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

No afiliado a StackOverflow