Início / dba / Perguntas / 64
Accepted
Beth Lang
Asked: 2011-01-04 15:23:26 +0800 CST

Existe um processo do tipo "práticas recomendadas" para os desenvolvedores seguirem para alterações no banco de dados?

  • 772

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

  1. Faça o script da alteração em um arquivo SQL e anexe-o 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 estiver pronto para produção, o SQL será executado nos bancos de dados de produção.

O problema com isso é que é muito manual. Ele depende do desenvolvedor se lembrar de anexar o sql ou do revisor de pares, caso o desenvolvedor se esqueça. Às vezes, acaba sendo o testador ou o implementador de controle de qualidade quem descobre o problema.

Um problema secundário é que às vezes você acaba precisando coordenar manualmente as alterações se duas tarefas separadas alterarem o mesmo objeto de banco de dados. Pode ser assim, mas ainda parece que deve haver alguma 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 de .NET e MS SQL. Atualmente, estamos usando itens de trabalho do MS TFS para rastrear nosso trabalho. Isso é útil para alterações de código porque vincula os conjuntos de alterações aos itens de trabalho para que eu possa descobrir exatamente quais alterações preciso incluir ao migrar para ambientes de controle de qualidade e produção. No momento, não estamos usando um projeto de banco de dados, mas podemos mudar para ele no futuro (talvez isso seja parte da resposta).

Estou muito acostumado com meu sistema de controle de origem cuidando de coisas assim para mim e gostaria de ter o mesmo para meu SQL.

sql-server-2008 process

5 respostas

  1. Best Answer

    Em um ambiente VS, 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 me permite vinculá-los a tarefas e bugs do Team Server (e, se fizermos revisões de código, a eles também). Também incluo em cada banco de dados (sobre o qual tenho autoridade) uma tabela específica para a coleta 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, bem como o final de um patch. Os eventos que acontecem fora dos patches são coisas a serem observadas.

    Por exemplo, uma inserção "begin patch" 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 ele também detecta quando os índices são reconstruídos, você precisará executar o seguinte a cada mês ou mais 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 postada anteriormente em 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 de antemão. Os comentários no topo dos scripts de atualização incluem listas de novas tabelas, stored procs, funções, etc, bem como listas de tabelas modificadas, stored procs, 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ê acaba precisando coordenar manualmente as alterações se duas tarefas separadas alterarem o mesmo objeto de banco de dados. Pode ser assim, mas ainda parece que deve haver alguma maneira automatizada de "sinalizar" esses problemas ou algo assim.

    Nunca encontrei uma ferramenta que nos permitisse rastrear isso automaticamente. Os empregadores anteriores usavam o princípio do "proprietário do banco de dados" - uma e apenas uma pessoa pessoalmente encarregada do banco de dados. Essa pessoa não será o único desenvolvedor trabalhando nesse banco de dados, mas todas as alterações devem passar por eles. Isso funcionou razoavelmente bem para evitar que as alterações colidissem e se danificassem.

    • 17

  2. Você já olhou para 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/

    • 7

  3. 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, os 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 verificados no controle de origem. Grandes alterações são revisadas por pares e o PowerDesigner torna isso muito fácil usando recursos integrados.

    O PowerDesigner é uma ferramenta de modelagem genérica que suporta mais do que apenas bancos de dados, então estamos começando a usá-lo para gerenciar requisitos, criar diagramas conceituais, físicos e de arquitetura (OOM's também), etc. Basicamente, estamos usando-o para fornecer o backbone para o nosso processo de engenharia de software.

    (Não sou de forma alguma afiliado à Sybase, que desenvolveu o PowerDesigner - apenas pensei em incluir isso).

    • 4

  4. banco de dados fantasma

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

    Benefícios

    1. Todos os objetos em seu banco de dados são armazenados como scripts no controle de origem.
    2. Você também pode criar scripts de 'dados estáticos' (dados da tabela de pesquisa).
    3. Você pode atualizar o controle de origem manualmente ou criando um script de banco de dados de desenvolvimento 'modelo'.
    4. Você pode construir um banco de dados (rapidamente) a partir dos scripts no controle de origem (incluindo dados estáticos).
    5. Você pode implantar alterações em 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 que crio 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 em relação à manutenção de scripts explícitos de mudança ou migração é que você não precisa manter scripts explícitos de mudança ou migração – você pode manter apenas a 'versão atual' de 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 de manusear como scripts separados.

    Uma consequência particularmente boa de ser capaz de gerenciar bancos de dados como (um conjunto) de scripts e também de criar rapidamente novas instâncias é que o teste de unidade de código de banco de dados importante é muito fácil (e muito divertido também). Eu uso tSQLt para testes de unidade.

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

    • 2

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

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

    Sql Server também é suportado, mas você pode ter que usar JRuby + JDBC.

    • 1

relate perguntas