Você usa o controle de origem para os itens do banco de dados? [fechadas]

Sinto que minha loja tem um buraco porque não temos um processo sólido para a versão de nossas alterações no esquema do banco de dados. Como fazemos muitos backups, estamos mais ou menos cobertos, mas é uma prática ruim confiar na sua última linha de defesa dessa maneira.

Surpreendentemente, isso parece ser um fio comum. Muitas lojas com as quais falei ignoram esse problema porque seus bancos de dados não mudam frequentemente e basicamente tentam ser meticulosos.

No entanto, eu sei como é essa história. É apenas uma questão de tempo até que as coisas se alinhem e algo falte.

Existem práticas recomendadas para isso? Quais são algumas estratégias que funcionaram para você?

Deve ler Obtenha seu banco de dados sob controle de versão . Confira a série de posts de K. Scott Allen.

Quando se trata de controle de versão, o banco de dados geralmente é um cidadão de segunda ou terceira classe. Pelo que vi, equipes que nunca pensariam em escrever código sem controle de versão em um milhão de anos - e com razão - podem, de alguma forma, ignorar completamente a necessidade de controle de versão nos bancos de dados críticos nos quais seus aplicativos se baseiam. Não sei como você pode se chamar um engenheiro de software e manter uma cara séria quando seu banco de dados não está exatamente no mesmo nível rigoroso de controle de origem que o resto do seu código. Não deixe isso acontecer com você. Coloque seu banco de dados sob controle de versão.

Os próprios bancos de dados? Não

Os scripts que os criam, incluindo inserções de dados estáticas, procedimentos armazenados e similares; claro. São arquivos de texto, estão incluídos no projeto e fazem check-in e check-out como todo o resto.

Obviamente, em um mundo ideal, sua ferramenta de gerenciamento de banco de dados faria isso; mas você só precisa ser disciplinado.

Eu absolutamente amo migrações do Rails ActiveRecord. Ele abstrai o script DML para ruby, que pode ser facilmente versionado em seu repositório de origem.

No entanto, com um pouco de trabalho, você pode fazer a mesma coisa. Quaisquer alterações de DDL (ALTER TABLE, etc.) podem ser armazenadas em arquivos de texto. Mantenha um sistema de numeração (ou um carimbo de data) para os nomes dos arquivos e aplique-os em sequência.

O Rails também possui uma tabela 'version' no banco de dados que controla a última migração aplicada. Você pode fazer o mesmo facilmente.

Confira o LiquiBase para gerenciar alterações no banco de dados usando o controle de origem.

Você nunca deve fazer login e começar a digitar os comandos "ALTER TABLE" para alterar um banco de dados de produção. O projeto em que estou possui um banco de dados em cada site do cliente e, portanto, todas as alterações no banco de dados são feitas em dois locais, um arquivo de despejo usado para criar um novo banco de dados em um novo site do cliente e um arquivo de atualização executado em todas as atualizações que comparem o número da versão atual do banco de dados com o número mais alto do arquivo e atualizam o banco de dados no local. Por exemplo, as últimas atualizações:

if [ $VERSION \< '8.0.108' ] ; then
  psql -U cosuser $dbName << EOF8.0.108
    BEGIN TRANSACTION;
    --
    -- Remove foreign key that shouldn't have been there.
    -- PCR:35665
    --
    ALTER TABLE     migratorjobitems
    DROP CONSTRAINT migratorjobitems_destcmaid_fkey;
    -- 
    -- Increment the version
    UPDATE          sys_info
    SET             value = '8.0.108'
    WHERE           key = 'DB VERSION';
    END TRANSACTION;
EOF8.0.108
fi

if [ $VERSION \< '8.0.109' ] ; then
  psql -U cosuser $dbName << EOF8.0.109
    BEGIN TRANSACTION;
    --
    -- I missed a couple of cases when I changed the legacy playlist
    -- from reporting showplaylistidnum to playlistidnum
    --
    ALTER TABLE     featureidrequestkdcs
    DROP CONSTRAINT featureidrequestkdcs_cosfeatureid_fkey;
    ALTER TABLE     featureidrequestkdcs
    ADD CONSTRAINT  featureidrequestkdcs_cosfeatureid_fkey
    FOREIGN KEY     (cosfeatureid)
    REFERENCES      playlist(playlistidnum)
    ON DELETE       CASCADE;
    --
    ALTER TABLE     ticket_system_ids
    DROP CONSTRAINT ticket_system_ids_showplaylistidnum_fkey;
    ALTER TABLE     ticket_system_ids
    RENAME          showplaylistidnum
    TO              playlistidnum;
    ALTER TABLE     ticket_system_ids
    ADD CONSTRAINT  ticket_system_ids_playlistidnum_fkey
    FOREIGN KEY     (playlistidnum)
    REFERENCES      playlist(playlistidnum)
    ON DELETE       CASCADE;
    -- 
    -- Increment the version
    UPDATE          sys_info
    SET             value = '8.0.109'
    WHERE           key = 'DB VERSION';
    END TRANSACTION;
EOF8.0.109
fi

Tenho certeza de que há uma maneira melhor de fazer isso, mas funcionou para mim até agora.

Sim. Código é código. Minha regra geral é que preciso criar e implantar o aplicativo do zero , sem olhar para uma máquina de desenvolvimento ou produção.

A melhor prática que eu vi foi criar um script de construção para descartar e reconstruir seu banco de dados em um servidor intermediário. Cada iteração recebeu uma pasta para alterações no banco de dados, todas as alterações foram escritas com "Drop ... Create" 's. Dessa forma, você pode reverter para uma versão anterior a qualquer momento, apontando a compilação para a pasta na qual deseja fazer a versão.

Acredito que isso foi feito com o NaNt / CruiseControl.

SIM, acho importante atualizar seu banco de dados. Não os dados, mas o esquema, com certeza.

No Ruby On Rails, isso é tratado pela estrutura com "migrações". Sempre que você altera o banco de dados, você cria um script que aplica as alterações e o verifica no controle de origem.

Minha loja gostou tanto dessa idéia que adicionamos a funcionalidade à nossa compilação baseada em Java usando shell scripts e Ant. Integramos o processo à nossa rotina de implantação. Seria bastante fácil escrever scripts para fazer a mesma coisa em outras estruturas que não oferecem suporte à versão do DB pronta para uso.

Os novos projetos de banco de dados no Visual Studio fornecem controle de origem e scripts de alteração.

Eles têm uma boa ferramenta que compara bancos de dados e pode gerar um script que converte o esquema de um para o outro ou atualiza os dados em um para corresponder ao outro.

O esquema db é "fragmentado" para criar muitos arquivos .sql pequenos, um por comando DDL que descreve o banco de dados.

+ tom

Informações adicionais 30/11/2008

Eu tenho usado como desenvolvedor durante o ano passado e realmente gosto. Isso facilita a comparação do meu trabalho de desenvolvimento com a produção e a geração de um script para usar no lançamento. Não sei se faltam recursos que os DBAs precisam para projetos de "tipo empresarial".

Como o esquema é "fragmentado" em arquivos sql, o controle de origem funciona bem.

Uma dica é que você precisa ter uma mentalidade diferente ao usar um projeto db. A ferramenta possui um "projeto de banco de dados" no VS, que é apenas o sql, além de um banco de dados local gerado automaticamente que possui o esquema e alguns outros dados de administrador - mas nenhum dos dados de seu aplicativo, além do banco de dados local dev que você usa para dados do aplicativo dev funcionar. Você raramente conhece o banco de dados gerado automaticamente, mas precisa conhecê-lo lá para poder deixá-lo em paz :). Esse banco de dados especial é claramente reconhecível porque possui um Guid em seu nome,

O Projeto VS DB faz um bom trabalho ao integrar alterações de banco de dados que outros membros da equipe fizeram no seu projeto local / banco de dados associado. mas você precisa executar a etapa extra para comparar o esquema do projeto com o esquema local do dev db e aplicar os mods. Faz sentido, mas parece estranho no começo.

DB Projects são uma ferramenta muito poderosa. Eles não apenas geram scripts, mas podem aplicá-los imediatamente. Certifique-se de não destruir seu banco de dados de produção com ele. ;)

Eu realmente gosto dos projetos do VS DB e espero usar essa ferramenta para todos os meus projetos de banco de dados daqui para frente.

+ tom

Exigir que as equipes de desenvolvimento usem um sistema de gerenciamento de controle de origem de banco de dados SQL não é a mágica que impede que problemas ocorram. Por si só, o controle de origem do banco de dados introduz uma sobrecarga adicional, pois os desenvolvedores precisam salvar as alterações feitas em um objeto em um script SQL separado, abrir o cliente do sistema de controle de origem, fazer check-in no arquivo de script SQL usando o cliente e, em seguida, aplique as alterações ao banco de dados ativo.

Eu posso sugerir o uso do suplemento SSMS chamado ApexSQL Source Control . Ele permite que os desenvolvedores mapeiem facilmente objetos de banco de dados com o sistema de controle de origem por meio do assistente diretamente do SSMS. O suplemento inclui suporte para TFS, Git, Subversion e outros sistemas SC. Também inclui suporte para dados estáticos de controle de origem.

Após baixar e instalar o ApexSQL Source Control, clique com o botão direito do mouse no banco de dados que você deseja controlar a versão e navegue até o submenu ApexSQL Source Control no SSMS. Clique na opção Vincular banco de dados ao controle de origem, selecione o sistema de controle de origem e o modelo de desenvolvimento. Depois disso, você precisará fornecer as informações de login e a cadeia de repositórios para o sistema de controle de origem que você escolheu.

Você pode ler este artigo para obter mais informações: http://solutioncenter.apexsql.com/sql-source-control-reduce-database-development-time/

Faço isso salvando scripts de criação / atualização e um script que gera dados de amostra.

Sim, fazemos isso mantendo nosso SQL como parte de nossa compilação - mantemos DROP.sql, CREATE.sql, USERS.sql, VALUES.sql e controle de versão, para que possamos reverter para qualquer versão marcada.

Também temos tarefas ant que podem recriar o banco de dados sempre que necessário.

Além disso, o SQL é marcado juntamente com o código fonte que o acompanha.

O esquema mais bem-sucedido que já usei em um projeto combinou backups e arquivos SQL diferenciais. Basicamente, faríamos um backup do nosso banco de dados após cada release e faríamos um dump SQL, para que pudéssemos criar um esquema em branco do zero, se necessário. Então, sempre que você precisar fazer uma alteração no banco de dados, adicione um script de alteração ao diretório sql sob controle de versão. Sempre prefixaríamos um número de seqüência ou data no nome do arquivo, para que a primeira alteração fosse algo como 01_add_created_on_column.sql, e o próximo script seria 02_added_customers_index. Nossa máquina de CI verifica esses e os executa sequencialmente em uma nova cópia do banco de dados restaurada a partir do backup.

Também tínhamos alguns scripts em vigor que os desenvolvedores poderiam usar para reinicializar o banco de dados local na versão atual com um único comando.

Nós controlamos a origem de todos os nossos objetos criados no dabase. E apenas para manter os desenvolvedores honestos (como você pode criar objetos sem que eles estejam no Source Control), nossos dbas procuram periodicamente qualquer coisa que não esteja no controle de origem e, se encontrarem alguma coisa, descartam-na sem perguntar se está ok.

Eu uso o SchemaBank para controlar a versão de todas as minhas alterações de esquema do banco de dados:

• desde o dia 1, importo meu db do esquema db nele
• Comecei a mudar meu design de esquema usando um navegador da Web (porque eles são baseados em SaaS / nuvem)
• quando eu quero atualizar meu servidor db, eu giro o script change (SQL) a partir dele e aplico ao db. No Schemabank, eles me mandam comprometer meu trabalho como uma versão antes que eu possa gerar um script de atualização. Eu gosto desse tipo de prática, para que eu possa sempre rastrear quando precisar.

Nossa regra da equipe NUNCA é tocar no servidor db diretamente, sem armazenar primeiro o trabalho de design. Mas acontece que alguém pode ser tentado a quebrar a regra, por uma questão de conveniência. Importaríamos o dump do esquema novamente para o schemabank e permitiríamos que ele fizesse o diff e bash alguém se uma discrepância fosse encontrada. Embora pudéssemos gerar os scripts alter para fazer o design do nosso banco de dados e esquema em sincronia, odiamos isso.

A propósito, eles também nos permitem criar ramificações na árvore de controle de versão, para que eu possa manter uma para preparação e outra para produção. E um para codificar sandbox.

Uma ferramenta de design de esquema bem baseada na Web, com controle de versão e gerenciamento de alterações.

Eu tenho todo o necessário para recriar meu banco de dados a partir do bare metal, menos os dados em si. Tenho certeza de que existem várias maneiras de fazer isso, mas todos os meus scripts são armazenados no subversion e podemos reconstruir a estrutura do banco de dados, retirando tudo isso do subversion e executando um instalador.

Normalmente, construo um script SQL para cada alteração que faço e outro para reverter essas alterações e manter esses scripts sob controle de versão.

Depois, temos um meio de criar um novo banco de dados atualizado sob demanda e podemos alternar facilmente entre as revisões. Toda vez que fazemos um lançamento, agrupamos os scripts (leva um pouco de trabalho manual, mas raramente é realmente difícil ), por isso também temos um conjunto de scripts que podem ser convertidos entre versões.

Sim, antes que você diga, isso é muito parecido com o que o Rails e outros fazem, mas parece funcionar muito bem, então não tenho problemas em admitir que levantei a ideia descaradamente :)

Eu uso scripts SQL CREATE exportados do MySQL Workbech e, em seguida, usando a funcionalidade "Exportar SQL ALTER", termino com uma série de scripts de criação (numerados, é claro) e os scripts de alteração que podem aplicar as alterações entre eles.

3.- Exportar script SQL ALTER Normalmente, você teria que escrever as instruções ALTER TABLE à mão agora, refletindo as alterações feitas no modelo. Mas você pode ser inteligente e deixar o Workbench fazer o trabalho duro por você. Simplesmente selecione Arquivo -> Exportar -> Script SQL ALTER do Forward Engineer… no menu principal.

Isso solicitará que você especifique o arquivo SQL CREATE com o qual o modelo atual deve ser comparado.

Selecione o script SQL CREATE na etapa 1. A ferramenta gerará o script ALTER TABLE para você e você poderá executar esse script no seu banco de dados para atualizá-lo.

Você pode fazer isso usando o MySQL Query Browser ou o mysql client.Voila! Seu modelo e banco de dados já foram sincronizados!

Fonte: MySQL Workbench Community Edition: Guia para sincronização de esquema

É claro que todos esses scripts estão dentro de controle de versão.

Sim, sempre. Você deve recriar a estrutura do banco de dados de produção com um conjunto útil de dados de amostra sempre que necessário. Se não o fizer, com o tempo, pequenas alterações para manter as coisas funcionando serão esquecidas, e um dia você será mordido, muito tempo. É o seguro que você pode achar que não precisa, mas no dia em que faz isso vale 10 vezes o preço!

Houve muita discussão sobre o próprio modelo de banco de dados, mas também mantemos os dados necessários em arquivos .SQL.

Por exemplo, para ser útil, seu aplicativo pode precisar disso na instalação:

INSERT INTO Currency (CurrencyCode, CurrencyName) 
VALUES ('AUD', 'Australian Dollars');

INSERT INTO Currency (CurrencyCode, CurrencyName) 
VALUES ('USD', 'US Dollars');

Teríamos um arquivo chamado currency.sqlsob subversão. Como uma etapa manual do processo de compilação, comparamos o currency.sql anterior com o mais recente e escrevemos um script de atualização.

Nós controlamos a versão e o código-fonte de tudo que envolve nossos bancos de dados:

• DDL (criar e alterar)
• DML (dados de referência, códigos, etc.)
• Alterações no modelo de dados (usando ERwin ou ER / Studio)
• Alterações na configuração do banco de dados (permissões, objetos de segurança, alterações gerais na configuração)

Fazemos tudo isso com trabalhos automatizados usando o Change Manager e alguns scripts personalizados. Temos o Change Manager monitorando essas alterações e notificando quando elas são concluídas.

Acredito que todo banco de dados deve estar sob controle de origem e os desenvolvedores devem ter uma maneira fácil de criar seu banco de dados local do zero. Inspirado no Visual Studio para profissionais de banco de dados, criei uma ferramenta de código aberto que cria scripts para bancos de dados MS SQL e fornece uma maneira fácil de implantá-los no mecanismo de banco de dados local. Tente http://dbsourcetools.codeplex.com/ . Divirta-se, Nathan.

Se o seu banco de dados for o SQL Server, talvez tenhamos a solução que você está procurando. O SQL Source Control 1.0 foi lançado agora.

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

Isso se integra ao SSMS e fornece a cola entre seus objetos de banco de dados e seu VCS. O 'script fora' acontece de forma transparente (ele usa o mecanismo SQL Compare sob o capô), o que deve tornar tão simples o uso que os desenvolvedores não serão desencorajados a adotar o processo.

Uma solução alternativa do Visual Studio é o ReadyRoll , que é implementado como um subtipo do Projeto de Banco de Dados SSDT. Isso adota uma abordagem orientada a migrações, mais adequada aos requisitos de automação das equipes de DevOps.

Eu controle o código do esquema do banco de dados criando scripts para todos os objetos (definições de tabela, índices, procedimentos armazenados etc.). Mas, quanto aos dados em si, basta confiar em backups regulares. Isso garante que todas as alterações estruturais sejam capturadas com o histórico de revisões adequado, mas não sobrecarregará o banco de dados toda vez que os dados forem alterados.

Em nossos negócios, usamos scripts de alteração de banco de dados. Quando um script é executado, seu nome é armazenado no banco de dados e não será executado novamente, a menos que a linha seja removida. Os scripts são nomeados com base na data, hora e ramo do código, portanto, a execução controlada é possível.

Muitos testes são feitos antes que os scripts sejam executados no ambiente ao vivo; portanto, os "oopsies" só acontecem, de um modo geral, nos bancos de dados de desenvolvimento.

Estamos no processo de mover todos os bancos de dados para o controle de origem. Estamos usando o sqlcompare para criar scripts para o banco de dados (um recurso de edição profissional, infelizmente) e colocar esse resultado no SVN.

O sucesso da sua implementação dependerá muito da cultura e práticas da sua organização. As pessoas aqui acreditam na criação de um banco de dados por aplicativo. Há um conjunto comum de bancos de dados que são usados ​​pela maioria dos aplicativos, causando muitas dependências entre bancos de dados (alguns são circulares). Colocar os esquemas de banco de dados no controle de origem tem sido notoriamente difícil por causa das dependências entre bancos de dados que nossos sistemas possuem.

Boa sorte para você, quanto mais cedo você tentar, mais cedo terá seus problemas resolvidos.

Eu usei a ferramenta dbdeploy da ThoughtWorks em http://dbdeploy.com/ . Ele incentiva o uso de scripts de migração. A cada versão, consolidamos os scripts de mudança em um único arquivo para facilitar o entendimento e permitir que os DBAs 'abençoem' as mudanças.

Isso sempre foi um grande aborrecimento para mim também - parece que é muito fácil fazer uma alteração rápida no banco de dados de desenvolvimento, salvá-lo (esquecendo de salvar um script de alteração) e então você fica preso. Você pode desfazer o que acabou de fazer e refazê-lo para criar o script de alteração ou escrevê-lo do zero, se você quiser, é claro, também, embora isso gaste muito tempo escrevendo scripts.

Uma ferramenta que eu usei no passado que ajudou com isso é o SQL Delta. Ele mostrará as diferenças entre dois bancos de dados (SQL Server / Oracle, acredito) e gerará todos os scripts de alteração necessários para migrar A-> B. Outra coisa interessante é mostrar todas as diferenças entre o conteúdo do banco de dados entre o banco de dados de produção (ou teste) e o banco de dados de desenvolvimento. Como mais e mais aplicativos armazenam a configuração e o estado que são cruciais para sua execução nas tabelas do banco de dados, pode ser um grande problema ter scripts de alteração que removem, adicionam e alteram as linhas apropriadas. O delta do SQL mostra as linhas no banco de dados da mesma forma que pareceriam em uma ferramenta Diff - alteradas, adicionadas e excluídas.

Uma excelente ferramenta. Aqui está o link: http://www.sqldelta.com/

O RedGate é ótimo, geramos novos instantâneos quando são feitas alterações no banco de dados (um pequeno arquivo binário) e mantemos esse arquivo nos projetos como um recurso. Sempre que precisamos atualizar o banco de dados, usamos o kit de ferramentas do RedGate para atualizar o banco de dados, além de poder criar novos bancos de dados a partir dos vazios.

O RedGate também faz snapshots de dados, embora eu não tenha trabalhado pessoalmente com eles, eles são igualmente robustos.

FYI Isso também foi mencionado há alguns dias por Dana ... Procedimentos armazenados / esquema de banco de dados no controle de origem