Implementación de bases de datos SQL Server de Test a Live

Para mis proyectos alterno entre SQL Compare de REd Gate y el Asistente de Publicación de Bases de datos de Microsoft que se puede descargar gratis aquí.

El Asistente no es tan hábil como SQL Compare o SQL Data Compare, pero hace el truco. Un problema es que los scripts que genera pueden necesitar algún reordenamiento y / o edición para fluir en una sola toma.

En el lado positivo, puede mover su esquema y datos, lo que no está mal para una herramienta gratuita.

No olvide la solución de Microsoft al problema: Visual Studio 2008 Database Edition. Incluye herramientas para implementar cambios en bases de datos, producir una diferencia entre bases de datos para cambios de esquemas y/o datos, pruebas unitarias, 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 la base de datos sea tan fácil de trabajar como cualquier otra pieza de código.

Al igual que Rob Allen, uso SQL Compare / Data Compare by Redgate. También uso 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 comandos o en un script por lotes.

Uso Microsoft.SQLServer.BatchParser.dll y Microsoft.SQLServer.ConnectionInfo.bibliotecas dll en la aplicación de consola.

Trabajo de la misma manera que Karl, manteniendo todos mis scripts SQL para crear y alterar tablas en un archivo de texto que guardo en el control de código fuente. De hecho, para evitar el problema de tener que tener un script examinar la base de datos en vivo para determinar lo que altera a ejecutar, por lo general trabajo así:

• En la primera versión, coloco todo durante la prueba en un script SQL, y trato todas las tablas como una CREACIÓN. Esto significa que termino cayendo y leyendo tablas mucho durante las pruebas, pero eso no es un gran problema al principio del proyecto (ya que generalmente estoy hackeando los datos que estoy usando en ese momento de todos modos).
• En todas las versiones posteriores, hago dos cosas: hago un nuevo archivo de texto para contener los scripts SQL de actualización, que contienen solo los cambios para esa versión. Y hago los cambios en el original, crear un nuevo script de base de datos también. De esta manera, una actualización solo ejecuta el script de actualización, pero si tenemos que recrear la base de datos no necesitamos ejecutar 100 scripts para obtener alli.
• Dependiendo de cómo esté implementando los cambios en la BD, también pondré una tabla de versiones en la BD que contenga la versión de la BD. Entonces, en lugar de tomar decisiones humanas sobre qué scripts ejecutar, cualquier código que tenga ejecutando los scripts de create/upgrade usa la versión para determinar qué ejecutar.

La única cosa que esto no hará es ayudar si parte de lo que estás moviendo de la prueba a la producción son datos, pero si quieres administrar la estructura y no pagar por una buena, pero costoso paquete de gestión de bases de datos, realmente no es muy difícil. También he encontrado que es una muy buena manera de mantener un seguimiento mental de su DB.

Si tiene una empresa que lo compra, Toad de Quest Software tiene este tipo de funcionalidad de gestión incorporada. Es básicamente una operación de dos clics para comparar dos esquemas y generar un script de sincronización de uno a otro.

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

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 así factibles.

En general, tomo el enfoque de "Script It", pero es posible que desee considerar algo en este sentido:

• Distinga entre Desarrollo y Estadificación, de modo que pueda Desarrollarse con un subconjunto de datos ... esto me gustaría crear una herramienta para simplemente tirar hacia abajo algunos datos de producción,o generar datos falsos en lo que respecta a la seguridad.
• Para el equipo desarrollo, cada cambio en la base de datos tendrá que ser coordinado entre los miembros de su equipo. Los cambios de esquema y datos se pueden mezclar, pero un solo script debe habilitar una característica determinada. Una vez que todas sus características estén listas, las agrupará en un solo archivo SQL y las ejecutará en una restauración de producción.
• Una vez que la fase provisional haya borrado la aceptación, ejecute de nuevo el único archivo SQL en la máquina de producción.

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

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

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

Estoy de acuerdo con mantener todo en control de código fuente y crear scripts manuales para todos los cambios. Los cambios en el esquema de una sola versión se introducen en un archivo de script creado específicamente para esa versión. Todos los procs almacenados, vistas, etc. deben ir a archivos individuales y tratados de la misma manera .cs or .aspx en lo que respecta al control de código fuente. Utilizo un script de Powershell para generar uno grande .archivo sql para actualizar las cosas de programabilidad.

No me gusta automatizar la aplicación de cambios de esquema, como nuevas tablas, columnas, etc. Al hacer una versión de producción, me gusta ir a través del script de cambios comando por comando para asegurarse de que cada uno funciona como se espera. No hay nada peor que ejecutar un gran script de cambios en la producción y obtener errores porque olvidaste algunos pequeños detalles que no se presentaron en el desarrollo.

También he aprendido que los índices deben ser tratados como archivos de código y puestos en control de código fuente.

Y definitivamente deberías tener más de 2 bases de datos-dev y live. Usted debe tener una base de datos dev que todo el mundo utiliza para las tareas diarias dev. A continuación, una base de datos provisional que imita la producción y se utiliza para realizar las pruebas de integración. Entonces tal vez una copia reciente completa de producción (restaurada a partir de una copia de seguridad completa), si eso es factible, por lo que su última ronda de pruebas de instalación va en contra de algo que es lo más cercano a la cosa real como sea posible.

Estoy usando el mecanismo de migraciones de Subsonic, así que solo tengo una dll con clases en orden squential que tienen 2 métodos, arriba y abajo. Hay un gancho de script de integración/compilación continuo en nant, para que pueda automatizar la actualización de mi base de datos.

No es el mejor thign del mundo, pero es mejor que escribir DDL.

RedGate SqlCompare es un camino a seguir en mi opinión. Hacemos el despliegue de bases de datos de forma regular y desde que empecé a usar esa herramienta nunca he mirado hacia atrás. Interfaz muy intuitiva y ahorra mucho tiempo al final.

La versión Pro también se encargará de la creación de scripts para la integración del control de código 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 el lote dentro de una transacción.

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 esquema maint en código. Esto también significa que si uno necesita hacer cosas no DDL que no se asignan bien a SQL, puede escribir lógica de procedimiento y ejecutarla entre grumos de DDL/DML.

Mi dbs luego tiene una tabla que define la versión actual para que uno pueda codificar un conjunto relativamente sencillo de pruebas:

1. ¿Existe la base de datos? Si no crearlo.
2. ¿Es la BD la versión actual? Si no es así, ejecute los métodos, en secuencia, que actualizan el esquema (es posible que desee solicitar al usuario que confirme y, idealmente, realice copias de seguridad en este punto).

Para una aplicación de usuario único acabo de ejecutar esto en su lugar, para una aplicación web que actualmente para bloquear el usuario si las versiones no coinciden y tienen un esquema independiente maint aplicación que ejecutamos. Para multi-usuario dependerá de la entorno particular.

La ventaja? Bueno, tengo un nivel muy alto de confianza en que el esquema para las aplicaciones que utilizan esta metodología es consistente 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 la implementación de bases de datos de SQL Server desde test a live, sino también incluir todo el proceso desde Local - > Integración - > Test - > Producción. Así que lo que me puede hacer fácilmente todos los días es hacer NAnt tarea con Red-Gate SQL Compare. No estoy trabajando para RedGate pero tengo que decir que es una buena elección.