Qual é uma boa maneira de migrar as alterações de banco de dados dos ambientes de desenvolvimento para o controle de qualidade e de produção? Atualmente nós:

1. Script a alteração em um arquivo SQL e anexe-a a um item de trabalho do TFS.
2. O trabalho é revisado por pares
3. Quando o trabalho estiver pronto para teste, o SQL será executado no controle de qualidade.
4. O trabalho é testado pelo controle de qualidade
5. Quando o trabalho está pronto para produção, o SQL é executado nos bancos de dados de produção.

O problema com isso é que é muito manual. Ele conta com o desenvolvedor lembrando de anexar o sql ou com o revisor por pares, se o desenvolvedor esquecer. Às vezes, acaba sendo o testador ou o implantador de controle de qualidade que descobre o problema.

Um problema secundário é que, às vezes, você precisa coordenar manualmente as alterações se duas tarefas separadas alterarem o mesmo objeto de banco de dados. Pode ser que seja assim, mas ainda parece que deve haver uma maneira automatizada de "sinalizar" esses problemas ou algo assim.

Nossa configuração: Nossa loja de desenvolvimento está cheia de desenvolvedores com muita experiência em banco de dados. Nossos projetos são muito orientados a DB. Somos principalmente uma loja .NET e MS SQL. Atualmente, estamos usando os itens de trabalho do MS TFS para rastrear nosso trabalho. Isso é útil para alterações de código, pois vincula os conjuntos de alterações aos itens de trabalho, para que eu possa descobrir exatamente quais alterações eu preciso incluir ao migrar para os ambientes de controle de qualidade e produção. No momento, não estamos usando um projeto de banco de dados, mas podemos mudar para isso no futuro (talvez isso faça parte da resposta).

Estou muito acostumado ao meu sistema de controle de origem cuidando de coisas assim para mim e gostaria de ter a mesma coisa para o meu SQL.

Em um ambiente do VS, eu sempre usei projetos de banco de dados para implementar os scripts de atualização. Costumo usar nomes sem imaginação, como "DatabaseUpdate17.sql" ou "PriceUpdateFebruary2010.sql" para meus scripts. Tê-los como projetos de banco de dados permite vinculá-los às tarefas e erros do Team Server (e se fizemos análises de código a eles também). Também incluo em cada banco de dados (sobre o qual tenho autoridade) uma tabela especificamente para a coleção de alterações no 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

Bem, isso cuida de 3 dos 6 Ws .

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

Eu incluo uma instrução de inserção para registrar o início de um patch e o final de um patch. Eventos que acontecem fora dos patches são coisas a serem analisadas.

Por exemplo, uma inserção "patch inicial" para "patch 17" seria semelhante a:

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

Como também captura quando os índices são reconstruídos, você precisa executar o seguinte todos os meses para limpar esses 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

Versão anterior publicada anteriormente no Server Fault .

Em um ambiente compatível com SOX e PCI-DSS, você nunca terá acesso aos servidores de produção. Portanto, os scripts precisam ser claros e exercitados com antecedência. Os comentários na parte superior dos scripts de atualização incluem listas de novas tabelas, procs armazenados, funções, etc., bem como listas de tabelas modificadas, procs armazenados, funções etc. Se os dados forem modificados, explique o que está sendo modificado e por quê.

Um problema secundário é que, às vezes, você precisa coordenar manualmente as alterações se duas tarefas separadas alterarem o mesmo objeto de banco de dados. Pode ser que seja assim, mas ainda parece que deve haver uma maneira automatizada de "sinalizar" esses problemas ou algo assim.

Nunca me deparei com uma ferramenta que nos permita rastrear isso automaticamente. Empregadores anteriores usaram um princípio de "proprietário do banco de dados" - uma e apenas uma pessoa pessoalmente responsável pelo banco de dados. Essa pessoa não será o único desenvolvedor que trabalha nesse banco de dados, mas todas as alterações precisam passar por elas. Isso funcionou razoavelmente bem para impedir que as mudanças colidissem e danificassem umas às outras.

Você já olhou para o SQL Source Control? Você pode usá-lo para conectar seu SQL Server ao TFS / SVN / Vault ou VSS - http://www.red-gate.com/products/sql-development/sql-source-control/

Outra solução é usar algo como PowerDesigner, ERWin, etc. para projetar e gerenciar alterações em seu banco de dados.

Estamos começando a fazer a transição para uma política em que os bancos de dados são modelados no PowerDesigner. Todas as alterações na estrutura / código do banco de dados são feitas no modelo, verificadas no controle de origem e, em seguida, scripts de alteração são gerados a partir dos modelos para implementar as alterações no banco de dados. Esses scripts de alteração também são registrados no controle de origem. Grandes alterações são revisadas por pares e o PowerDesigner facilita muito o uso de recursos internos.

O PowerDesigner é uma ferramenta de modelagem genérica que suporta mais do que apenas bancos de dados, por isso estamos começando a usá-la para gerenciar requisitos, criar diagramas conceituais, físicos e de arquitetura (OOMs também) etc. Basicamente, estamos usando-a para fornecer a espinha dorsal de processo de engenharia de software.

(Eu não sou de forma alguma afiliado à Sybase, que desenvolveu o PowerDesigner - apenas pensei em lançar isso lá).

DB Ghost

O DB Ghost é minha ferramenta favorita para gerenciar bancos de dados.

Benefícios

1. Todos os objetos no seu banco de dados são armazenados como scripts no controle de origem.
2. Você também pode criar scripts para 'dados estáticos' (dados da tabela de pesquisa).
3. Você pode atualizar o controle de origem manualmente ou criando um script para um banco de dados de desenvolvimento 'modelo'.
4. Você pode criar um banco de dados (rapidamente) a partir dos scripts no controle de origem (incluindo dados estáticos).
5. Você pode implantar alterações nas instâncias do banco de dados, incluindo quaisquer instâncias de produção:
   • Você pode comparar um 'banco de dados de construção' (criado a partir dos scripts) com um banco de dados existente e gerar um script de alteração.
   • Você pode direcionar o DB Ghost para sincronizar automaticamente as alterações entre duas instâncias do banco de dados, por exemplo, um banco de dados de construção e seu banco de dados de produção.

[4] é particularmente útil para fazer alterações locais ou criar instâncias separadas para diferentes ambientes. Na verdade, é tão fácil criar um banco de dados separado para cada recurso ou bug em que trabalho que afeta um banco de dados.

Detalhes

A principal vantagem de usá-lo sobre a manutenção de scripts explícitos de mudança ou migração é que você geralmente não precisa manter scripts explícitos de mudança ou migração - você pode manter apenas a 'versão atual' do seu banco de dados. Um aspecto irritante do gerenciamento de scripts de migração é que não há uma maneira fácil de ver, por exemplo, uma lista de colunas em uma tabela (com base nos scripts de migração). É claro que algumas alterações precisam ser feitas como migrações explícitas, mas são fáceis o suficiente para serem manuseadas como scripts separados.

Uma conseqüência particularmente agradável de poder gerenciar bancos de dados como (um conjunto) de scripts e também criar rapidamente novas instâncias é que o teste de unidade de código importante do banco de dados é muito fácil (e muito divertido também). Eu uso o tSQLt para teste de unidade.

Eu só gostaria que houvesse uma ferramenta semelhante para outros DBMS-s.

Eu sei que parece um exagero para a maioria dos DBAs:

Você já pensou em usar o Ruby on Rails para rastrear as alterações no banco de dados (e somente as alterações no banco de dados). Você não precisa executar nenhum aplicativo ou escrever nenhum código ruby, etc. Mas achei o estilo das migrações (é assim que elas chamam): bastante útil: http://guides.rubyonrails.org/migrations.html

Sql Server também é suportado; talvez você precise usar o JRuby + JDBC.