c# - tortoise - Estrategias de implementación de bases de datos(SQL Server)

visual studio 2010 svn

Question

Estoy buscando una forma de hacer implementaciones diarias y mantener las secuencias de comandos de la base de datos en línea con las versiones.

Actualmente, tenemos una forma bastante decente de implementar nuestra fuente, tenemos cobertura de código de unidad, integración continua y procedimientos de reversión.

El problema es mantener las secuencias de comandos de la base de datos en línea con una versión. Todo el mundo parece probar el script en la base de datos de prueba y luego ejecutarlo en vivo, cuando las correlaciones de ORM se actualizan (es decir, los cambios se activan) y luego recoge la nueva columna.

El primer problema es que ninguno de los scripts DEBE escribirse en ningún lado, generalmente todos "intentan" ponerlos en una carpeta de Subversion pero algunas personas más perezosas solo ejecutan el script en vivo y la mayoría de las veces nadie sabe quién lo hizo que a la base de datos.

El segundo problema es que tenemos 4 bases de datos de prueba y están SIEMPRE fuera de línea y la única manera de alinearlas verdaderamente es haciendo una restauración desde la base de datos en vivo.

Soy un gran creyente de que un proceso como este debe ser simple, directo y fácil de usar para ayudar a un desarrollador, no obstaculizarlo.

Lo que estoy buscando son técnicas / ideas que hagan FÁCIL que el desarrollador desee registrar sus scripts de base de datos para que puedan ejecutarse como parte de un procedimiento de lanzamiento. Un proceso que el desarrollador querría seguir .

Cualquier historia, casos de uso o incluso un enlace sería útil.

Answer 1

Debería considerar usar una herramienta de compilación como MSBuild o NAnt. Utilizamos una combinación de CruiseControl.NET, NAnt y SourceGear Fortress para manejar nuestras implementaciones, incluidos los objetos SQL. La tarea de creación db de NAnt llama a sqlcmd.exe para actualizar las secuencias de comandos en nuestros entornos de desarrollo y preparación después de que se hayan registrado en Fortress.

Answer 2

El libro Refactoring Databases aborda muchos de estos problemas a nivel conceptual.

En cuanto a herramientas, sé que DB Ghost funciona bien para SQL Server. He oído que la edición Data Dude de Visual Studio realmente se ha mejorado en el último lanzamiento, pero no tengo ninguna experiencia con él.

En lo que respecta realmente al desarrollo continuo de la base de datos de estilo de integración, se hace realmente muy rápido gracias a la cantidad de copias de bases de datos que necesita. Es muy factible cuando la base de datos puede caber en una estación de trabajo de desarrollador pero no es práctica cuando la base de datos es tan grande que necesita ser desplegada en una grilla. Para hacerlo, necesita básicamente una copia de la base de datos por desarrollador [desarrolladores que realizan cambios de DDL, no solo cambios en los procesos] + 6 copias comunes. Las copias comunes son las siguientes:

1. INT DEV -> Los desarrolladores "controlan" su refactorización a INT DEV para las pruebas de integración. Cuando pasa la prueba de integración, esta base de datos se copia a DEV.
2. DEV -> Esta es la copia de desarrollo "oficial" de la base de datos. INT DEV se actualiza regularmente con una copia de DEV. Los desarrolladores que trabajan en nuevas refactorizaciones obtienen una copia nueva de la base de datos de DEV.
3. INT QA -> La misma idea que INT DEV excepto para el equipo de control de calidad. Cuando las pruebas de integración pasan aquí, esta base de datos se copia a QA y a DEV *.
4. Control de calidad
5. INT PROD -> La misma idea que INT QA excepto para producción. Cuando las pruebas de integración pasan aquí, esta base de datos se copia a PROD, QA * y DEV *
6. PINCHAR

* Al copiar bases de datos a través de líneas DEV / QA / PROD, también deberá ejecutar scripts para actualizar los datos de prueba relevantes para el entorno particular (por ejemplo, configurar usuarios de QA que el equipo de control de calidad usa para probar pero que no existen en producción) )

Answer 3

Escribí una herramienta basada en .NET para manejar las versiones de las bases de datos de manera automatizada. Hemos estado utilizando esta herramienta en producción para gestionar el despliegue de las actualizaciones de la base de datos (incluidos los parches) en múltiples entornos, mantener un registro en cada base de datos de los scripts que se han ejecutado y hacerlo todo de manera automatizada. Tiene una consola de línea de comandos para que pueda crear secuencias de comandos por lotes que utilizan esta herramienta. Compruébelo: https://github.com/bmontgomery/DatabaseVersioning

Answer 4

Gus sin ayuda mencionó a DB Ghost (arriba) - Lo secundo como una posible solución.

Una breve descripción de cómo mi empresa está utilizando DB Ghost:

• Después de que el esquema de un nuevo DB se haya resuelto razonablemente durante el desarrollo inicial, usamos DB Ghost ''Data and Schema Scripter'' para crear archivos de script (.sql) para todos los objetos DB (y cualquier información estática) y check-in estos archivos de script en control de origen (la herramienta separa los objetos en carpetas como "Procedimientos almacenados", "Tablas", etc.). En este punto, podemos usar cualquiera de las herramientas DB GHost ''Packager'' o ''Packager Plus'' para crear un ejecutable independiente para crear un nuevo DB a partir de estos scripts.
• Todos los cambios en el esquema de DB se registran en el origen mediante registros en los archivos de script específicos.
• En cualquier momento, podemos usar el paquete para crear un ejecutable para (a) crear un nuevo DB o (b) actualizar un DB existente. Se requiere cierta personalización para ciertos cambios dependientes de la ruta (por ejemplo, cambios que requieren la actualización de datos), pero tenemos scripts previos y posteriores a la actualización que se ejecutan.

El proceso de ''actualización'' implica la creación de una base de datos ''fuente'' limpia y luego (después de la pre-actualización de scripts personalizados), una comparación entre los esquemas de la base de datos fuente y la base de datos de destino. DB Ghost actualiza el DB de destino para que coincida

Realizamos cambios rutinarios en DB de producción (tenemos 14 clientes en 7 entornos de producción diferentes) pero implementamos inevitablemente un conjunto de cambios lo suficientemente grande con un ejecutable de actualización DB Ghost (creado durante nuestro proceso de compilación). Todos los cambios de producción que no se registraron en la fuente (o que no se registraron en la rama correspondiente que se libera) se pierden. Esto ha forzado a todos a realizar cambios de manera consistente.

Para resumir:

• Si aplica una política de que todas las actualizaciones de bases de datos se implementen utilizando un archivo ejecutable de actualización DB Ghost, puede ''forzar'' a los desarrolladores a registrar constantemente sus cambios, independientemente de si se implementan manualmente en el ínterin.
• Agregar un paso (o pasos) a su proceso de compilación para crear un ejecutable de actualización DB Ghost realizará una prueba para verificar que un DB se puede crear a partir de scripts (es decir, porque DB Ghost crea un DB ''fuente'', incluso cuando crea el paquete ejecutable de actualización) y si agrega un paso (o pasos) para ejecutar el paquete de actualización [en cualquiera de los cuatro DB de prueba que mencionó], puede mantener sus DB de prueba en línea con el origen.

Hay algunas advertencias y algunas limitaciones en cuanto a qué cambios se implementan ''fácilmente'' con esta herramienta (en realidad, un conjunto de herramientas relacionadas), pero todas son bastante menores (al menos para mi empresa):

• Cambiar el nombre de los objetos debe hacerse en uno de los scripts personalizados
• Toda la base de datos siempre se actualiza (por ejemplo, los objetos en un esquema individual no se pueden actualizar solos) lo que dificulta el soporte de los objetos específicos del cliente en la base de datos principal de la aplicación.

Answer 5

Hace algunos años que utilizamos SQL Compare de RedGate:

http://www.red-gate.com/products/index.htm

La versión pro tiene una interfaz de línea de comandos que probablemente pueda usar para configurar sus procedimientos de implementación.

Answer 6

Hay un montón de enlaces en estas publicaciones que deseo seguir (hice "mi propio" sistema hace años, tengo que ver si hay similitudes). Una cosa que necesitará, y que espero se mencione en estos enlaces, es la disciplina. No veo muy bien cómo puede funcionar cualquier sistema automático si alguien puede cambiar algo en cualquier momento. (Su pregunta implica que esto puede suceder en sus sistemas de producción, pero obviamente eso no puede ser cierto).

Tener una persona (el legendario "administrador de la base de datos") dedicada a la tarea de administrar los cambios en las bases de datos, en particular las bases de datos de producción, es una solución muy común. En cuanto a mantener la consistencia entre las bases de datos de desarrollo y prueba de X: si muchos usuarios lo utilizan, una vez más, lo mejor es que un individuo actúe como un "centro de intercambio de información" para los cambios; si todos tienen su propia instancia de base de datos, entonces son responsables de mantenerla en orden, y tener una "fuente" central consistente en la base de datos será crítica cuando necesiten una base de datos actualizada.

Aquí hay una publicación reciente de que puede ser de interés: how-to-refresh-a-test-instance-of-sql-server-with-production-data-without-using

Answer 7

Lea la serie de publicaciones de K.Scott Allen sobre el control de versiones de la base de datos .
Creamos una herramienta para aplicar scripts de bases de datos de forma controlada, basada en las técnicas que describe y funciona bien.
Esto podría usarse como parte del proceso de integración continua con cada base de datos de prueba que tenga implementados cambios cuando se realice una confirmación en la URL en la que se guardan los scripts de actualización de la base de datos. Sugeriría tener un script de línea base y actualizar scripts para que siempre puede ejecutar una secuencia de scripts para obtener una base de datos desde su versión actual hasta el nuevo estado que se necesita.
Sin embargo, esto todavía requiere algún proceso y disciplina por parte de los desarrolladores (todos los cambios deben ser transferidos a una nueva versión del script de instalación base y un script de parche).

Answer 8

Para este problema, elegí usar una herramienta de migración: Migratordotnet .

Con las migraciones (en cualquier herramienta) tiene una clase simple utilizada para realizar los cambios y deshacerlos. Aquí hay un ejemplo:

[Migration(62)]
public class _62_add_date_created_column : Migration
{
    public void Up()
    {
       //add it nullable
       Database.AddColumn("Customers", new Column("DateCreated", DateTime) );

       //seed it with data
       Database.Execute("update Customers set DateCreated = getdate()");

       //add not-null constraint
       Database.AddNotNullConstraint("Customers", "DateCreated");
    }

    public void Down()
    {
       Database.RemoveColumn("Customers", "DateCreated");
    }
}

Este ejemplo muestra cómo puede manejar actualizaciones volátiles, como agregar una nueva columna no nula a una tabla que tenga datos existentes. Esto se puede automatizar fácilmente, y puede subir y bajar fácilmente entre versiones.

Esta ha sido una adición realmente valiosa a nuestra construcción, y ha simplificado enormemente el proceso.

Publiqué una comparación de los diversos marcos de migración en .NET aquí: http://benscheirman.com/2008/06/net-database-migration-tool-roundup

Answer 9

Por lo que vale, este es un ejemplo real de un enfoque simple y de bajo costo utilizado por mi ex empleador (y que estoy tratando de impresionar en mi empleador actual como primer paso básico).

Agregue una tabla llamada ''DB_VERSION'' o similar. En CADA secuencia de comandos de actualización, agregue una fila a esa tabla que pueda incluir la cantidad de columnas que considere adecuada para describir la actualización, pero como mínimo sugeriría {VERSIÓN, DÍA DE EJECUCIÓN, DESCRIPCIÓN, UTILIZACIÓN DE LA EJECUCIÓN}. Ahora tiene un registro concreto de lo que ha estado sucediendo. Si alguien ejecuta su propio script no autorizado, deberá seguir el consejo de las respuestas anteriores, pero esto es solo una forma sencilla de mejorar drásticamente su control de versiones existente (es decir, ninguno).

Ahora tengamos un script de actualización de v2.1 a v2.2 de la base de datos y desee verificar que el tipo inconformista solitario realmente lo haya ejecutado en su base de datos, solo puede buscar las filas donde VERSIÓN = ''v2.2'' y si obtiene un resultado, no ejecute este script de actualización. Puede integrarse en una aplicación de utilidad de consola si es necesario.

Answer 10

Red Gate tiene un documento que describe cómo lograr la automatización de compilación: http://downloads.red-gate.com/HelpPDF/ContinuousIntegrationForDatabasesUsingRedGateSQLTools.pdf

Esto se basa en SQL Source Control , que se integra con SSMS y su sistema de control de fuente existente.

Answer 11

Si está tratando de mantener sincronizados los esquemas de la base de datos, intente utilizar Red Gate SQL Comparison SDK . Cree una base de datos temporal basada en un script de creación (newDb): así es como quiere que se vea su base de datos. Compare newDb con su base de datos anterior (oldDb). Obtenga un conjunto de cambios de esa comparación y aplíquelo usando Red Gate. Puedes construir este proceso de actualización en tus pruebas, y puedes intentar que todos los desarrolladores acepten que hay un lugar donde se guarda el script de creación para la base de datos. Esta misma práctica funciona bien para actualizar su base de datos en varias versiones y ejecutar secuencias de comandos y procesos de migración de datos entre cada paso (usando un documento XML para mapear los scripts de migración de creación y de datos)

Editar: con la técnica de Red Gate, solo le preocupa crear secuencias de comandos, no actualizar las secuencias de comandos, ya que Red Gate presenta la secuencia de comandos de actualización. También le permitirá soltar y crear índices, procedimientos almacenados, funciones, etc.

Answer 12

Una posible solución es estudiar la implementación de auditoría de DML en las bases de datos de prueba, y luego simplemente convertir esos registros de auditoría en una secuencia de comandos para las pruebas finales y la implementación en vivo. SQL Server 2008 mejora significativamente la auditoría de DML, pero incluso SQL Server 2005 lo admite mediante activadores.

Answer 13

Utilizamos Visual Studio para Database Professionals y TFS para versionar y administrar nuestras implementaciones de base de datos. Esto nos permite tratar nuestras bases de datos como el código (verificar, registrar, bloquear, ver el historial de versiones, realizar una ramificación, compilar, implementar, probar, etc.) e incluso incluirlos en los mismos archivos de la solución si lo deseamos.

Nuestros desarrolladores pueden trabajar en bases de datos locales para evitar pisar los cambios de los demás en un entorno compartido. Cuando verifican los cambios de la base de datos en TFS, tenemos una integración continua para construir, probar e implementar en nuestro entorno de desarrollo integrado. Tenemos versiones separadas en las ramas de publicación para crear scripts de implementación diferencial para cada entorno posterior.

Más tarde, si se descubre un error en un lanzamiento, podemos ir a una rama de lanzamiento y reparar el código y la base de datos al mismo tiempo.

Este es un gran producto, pero su adopción se vio obstaculizada desde el principio debido a un error de comercialización de Microsoft. Originalmente era un producto separado bajo Team System. Esto significaba que para utilizar las características de la edición de desarrollador y la edición de la base de datos al mismo tiempo, se requería que se intensificara la edición mucho más costosa de Team Suite. Nosotros (y muchos otros clientes) lamentamos a Microsoft por esto, y estamos muy contentos de que anunciaron este año que DB Pro se ha incluido en la edición de desarrollador , y que inmediatamente cualquier persona con licencia con edición de desarrollador puede instalar la edición de la base de datos.

Answer 14

Utilizamos una versión modificada del control de versiones de la base de datos descrita por K. Scott Allen . Usamos el Asistente de publicación de base de datos para crear el script de referencia original. Luego, una herramienta personalizada de C # basada en SQL SMO para volcar los procedimientos almacenados, las vistas y las funciones del usuario. Las herramientas de Red Gate generan scripts de cambio que contienen cambios de esquema y datos. Así que terminamos con una estructura como

Database/
    ObjectScripts/ - contains stored procs, views and user funcs 1-per file
    /baseline.sql - database snapshot which includes tables and data
    /sc.01.00.0001.sql - incremental change scripts
    /sc.01.00.0002.sql
    /sc.01.00.0003.sql

La herramienta personalizada crea la base de datos si es necesario, aplica baseline.sql si es necesario, agrega una tabla SchemaChanges si es necesario y aplica los scripts de cambios según sea necesario en función de lo que hay en la tabla SchemaChanges. Ese proceso ocurre como parte de una secuencia de comandos nant build cada vez que hacemos una implementación build a través de cc.net.

Si alguien quiere el código fuente de la aplicación schemachanger, puedo lanzarlo en codeplex / google o donde sea.

Answer 15

Ven aquí:

http://www.codinghorror.com/blog/archives/001050.html

Desplácese un poco hacia la lista de 5 enlaces al sitio web odetocode.com. Fantástica serie de cinco partes. Utilizaría eso como punto de partida para obtener ideas y descubrir un proceso que funcione para su equipo.