¿Cuál es una buena manera de migrar los cambios de DB de los entornos de Desarrollo a QA a Producción? Actualmente nosotros:

1. Script el cambio en un archivo SQL y adjúntelo a un elemento de trabajo TFS.
2. El trabajo es revisado por pares
3. Cuando el trabajo está listo para la prueba, el SQL se ejecuta en QA.
4. El trabajo es QA probado
5. Cuando el trabajo está listo para la producción, el SQL se ejecuta en las bases de datos de producción.

El problema con esto es que es muy manual. Se basa en que el desarrollador recuerde adjuntar el sql o que el revisor externo lo capture si el desarrollador se olvida. A veces, termina siendo el probador o el implementador de control de calidad que descubre el problema.

Un problema secundario es que a veces es necesario coordinar manualmente los cambios si dos tareas separadas cambian el mismo objeto de la base de datos. Esto puede ser así, pero parece que debería haber alguna forma automatizada de "marcar" estos problemas o algo así.

Nuestra configuración: nuestra tienda de desarrollo está llena de desarrolladores con mucha experiencia en DB. Nuestros proyectos están muy orientados a DB. Somos principalmente una tienda .NET y MS SQL. Actualmente estamos utilizando elementos de trabajo de MS TFS para rastrear nuestro trabajo. Esto es útil para los cambios de código porque vincula los conjuntos de cambios a los elementos de trabajo para que pueda averiguar exactamente qué cambios necesito incluir al migrar a los entornos de control de calidad y producción. Actualmente no estamos utilizando un proyecto de base de datos, pero podemos cambiar a eso en el futuro (tal vez eso sea parte de la respuesta).

Estoy muy acostumbrado a que mi sistema de control de código fuente se encargue de cosas como esta y me gustaría tener lo mismo para mi SQL.

En un entorno VS, siempre he usado proyectos de bases de datos para implementar los scripts de actualización. Tiendo a usar nombres poco imaginativos como "DatabaseUpdate17.sql" o "PriceUpdateFebruary2010.sql" para mis scripts. Tenerlos como proyectos de base de datos me permite vincularlos con tareas de Team Server, errores (y si hicimos revisiones de código, también con ellos). También incluyo en cada base de datos (sobre la que tengo autoridad) una tabla específicamente para la recopilación de cambios en el esquema.

CREATE TABLE [dbo].[AuditDDL](
    [EventID] [int] IDENTITY(1,1) PRIMARY KEY NOT NULL,
    [EventData] [xml] NULL,                    -- what did they do
    [EventUser] varchar(100) NOT NULL,         -- who did it
    [EventTime] [datetime] DEFAULT (getdate()) -- when did they do it
    )
GO

Bueno, eso se encarga de 3 de las 6 Ws .

CREATE TRIGGER [trgAuditDDL]
ON DATABASE 
FOR DDL_DATABASE_LEVEL_EVENTS 
AS
INSERT INTO AuditDDL(EventData, EventUser)
SELECT EVENTDATA(), original_login()
GO

Incluyo una declaración de inserción para registrar el comienzo de un parche, así como el final de un parche. Los eventos que ocurren fuera de los parches son aspectos a tener en cuenta.

Por ejemplo, un inserto de "inicio de parche" para "parche 17" se vería así:

INSERT INTO [dbo].[AuditDDL]
           ([EventData]
           ,[EventUser])
     VALUES
           ('<EVENT_INSTANCE><EventType>BEGIN PATCH 17</EventType></EVENT_INSTANCE>'
           ,ORIGINAL_LOGIN())
GO

Como también se detecta cuando se reconstruyen los índices, deberá ejecutar lo siguiente cada mes aproximadamente para eliminar esos eventos:

DELETE FROM AuditDDL
WHERE [EventData].exist('/EVENT_INSTANCE/EventType/text()[fn:contains(.,"ALTER_INDEX")]') =1
GO

DELETE FROM AuditDDL
WHERE [EventData].exist('/EVENT_INSTANCE/EventType/text()[fn:contains(.,"UPDATE_STATISTICS")]') =1
GO

Versión anterior publicada anteriormente en Server Fault .

En un entorno compatible con SOX y PCI-DSS, nunca tendrá acceso a los servidores de producción. Por lo tanto, los guiones deben ser claros y ejercidos de antemano. Los comentarios en la parte superior de los scripts de actualización incluyen listas de tablas nuevas, procesos almacenados, funciones, etc., así como listas de tablas modificadas, procesos almacenados, funciones, etc. Si los datos se modifican, explique qué se está modificando y por qué.

Un problema secundario es que a veces es necesario coordinar manualmente los cambios si dos tareas separadas cambian el mismo objeto de la base de datos. Esto puede ser así, pero parece que debería haber alguna forma automatizada de "marcar" estos problemas o algo así.

Nunca he encontrado una herramienta que nos permita rastrear esto automáticamente. Los empleadores anteriores usaban un principio de "propietario de la base de datos": una y solo una persona que está personalmente a cargo de la base de datos. Esta persona no será el único desarrollador que trabaja contra esa base de datos, sino que todos los cambios tienen que pasar por ellos. Esto ha funcionado razonablemente bien para evitar que los cambios choquen y se dañen entre sí.

¿Has mirado en SQL Source Control? Puede usarlo para conectar su SQL Server a TFS / SVN / Vault o VSS - http://www.red-gate.com/products/sql-development/sql-source-control/

Otra solución es usar algo como PowerDesigner, ERWin, etc. para diseñar y administrar cambios en su base de datos.

Estamos comenzando la transición a una política donde las bases de datos se modelan en PowerDesigner. Todos los cambios en la estructura / código de la base de datos se realizan en el modelo, se registran en el control de origen y luego los scripts de cambio se generan a partir de los modelos para implementar los cambios en la base de datos. Estos scripts de cambio también se registran en el control de origen. Los grandes cambios son revisados ​​por pares y PowerDesigner lo hace muy fácil usando las funciones integradas.

PowerDesigner es una herramienta de modelado genérica que admite más que solo bases de datos, por lo que estamos comenzando a usarla para administrar requisitos, crear diagramas conceptuales, físicos y de arquitectura (también de OOM), etc. Básicamente, la estamos usando para proporcionar la columna vertebral a nuestro proceso de ingeniería de software.

(De ninguna manera estoy afiliado a Sybase, que desarrolló PowerDesigner, solo pensé que lo incluiría allí).

DB Ghost

DB Ghost es mi herramienta favorita para administrar bases de datos.

Beneficios

1. Todos los objetos en su base de datos se almacenan como scripts en el control de origen.
2. También puede escribir 'datos estáticos' (datos de la tabla de búsqueda).
3. Puede actualizar el control de origen manualmente o mediante un script de una base de datos de desarrollo 'modelo'.
4. Puede crear una base de datos (rápidamente) a partir de los scripts en el control de origen (incluidos los datos estáticos).
5. Puede implementar cambios en las instancias de la base de datos, incluidas las instancias de producción:
   • Puede comparar una 'base de datos de compilación' (creada a partir de los scripts) con una base de datos existente y generar un script de cambio.
   • Puede indicar a DB Ghost que sincronice automáticamente los cambios entre dos instancias de la base de datos, por ejemplo, una base de datos de compilación y su base de datos de producción.

[4] es particularmente útil para realizar cambios locales o crear instancias separadas para diferentes entornos. De hecho, es tan fácil que creo una base de datos separada para cada característica o error en el que trabajo que impacta una base de datos.

Detalles

La principal ventaja de usarlo sobre el mantenimiento de scripts de cambio o migración explícitos es que, en su mayoría , no necesita mantener scripts de cambio o migración explícitos; en su mayoría, puede mantener solo la 'versión actual' de su base de datos. Un aspecto molesto de administrar los scripts de migración es que no hay una manera fácil de ver, por ejemplo, una lista de columnas en una tabla (basada en los scripts de migración). Por supuesto, algunos cambios deben realizarse como migraciones explícitas, pero son lo suficientemente fáciles de manejar como scripts separados.

Una consecuencia particularmente agradable de poder administrar bases de datos como (un conjunto) de scripts y también poder crear rápidamente nuevas instancias es que la prueba de la unidad del código de base de datos importante es muy fácil (y bastante divertido también). Yo uso tSQLt para pruebas unitarias.

Solo desearía que hubiera una herramienta similar para otros DBMS-s.

Sé que suena excesivo para la mayoría de los DBA:

¿Ha considerado usar Ruby on Rails para rastrear los cambios en la base de datos (y solo los cambios en la base de datos)? No necesita ejecutar ninguna aplicación ni escribir ningún código ruby, etc. Pero descubrí que el estilo de las migraciones (así lo llaman) es bastante útil: http://guides.rubyonrails.org/migrations.html

Sql Server también es compatible, aunque es posible que tenga que usar JRuby + JDBC.