Como você lida constantemente com as dimensões do banco de dados?

9

Nos últimos dois meses, mais ou menos, tenho procurado soluções ou práticas para lidar com o gerenciamento de versões nos bancos de dados. Estou procurando o que as pessoas veem como o melhor processo para lidar com isso.

Temos 3 ambientes para nossos bancos de dados:

Desenvolvimento
Teste de aceitação do usuário (UAT)
Produção

O problema é que às vezes estamos fazendo alterações em várias coisas em nosso banco de dados de desenvolvimento e, quando chega a hora de implantar, alguns dos recursos podem não estar prontos para serem liberados no UAT.

Recentemente, começamos a usar o controle Red Gate SQL Source para armazenar todas as nossas entidades (com confirmações regulares).

Eu estava pensando em basear-me nos conjuntos de alterações (ou seja, dizer que tudo, desde o conjunto de alterações X e o retorno agora estão sendo enviados para o UAT), no entanto, isso significa que as pessoas estão apenas verificando seu código no controle de origem antes de fazer uma implantação que pode ser confusa ( especialmente porque as pessoas esquecem). Outro problema com a abordagem do conjunto de alterações é se houver um bug em um procedimento armazenado que precise ser corrigido, o número do conjunto de alterações acabaria fora do escopo do nosso conjunto de alterações máximo para a revisão, tornando-o, portanto, necessário. Para recriar o banco de dados a partir de um conjunto de alterações máximo, enviaríamos o bug novamente.

Alguma sugestão sobre um processo?

obrigado

— judda
fonte

Parece que os scripts do banco de dados não estão no mesmo controle de origem que o código "real". Por que é isso? Você pode tratá-lo como "código-fonte" e colocá-lo com os ramos individuais?

— Mike M.

Atualmente, armazenamos apenas a versão de desenvolvimento dos scripts no controle de origem e o UAT / Production fica fora de sincronia com o desenvolvimento ativo. Cada um dos scripts no controle de origem é atualizado toda vez que um desenvolvedor faz uma confirmação. O problema com ramificações individuais é que temos um banco de dados centralizado que todos usam (para alterações maiores, ramificamos os bancos de dados separados).

11

Você pode criar uma ramificação para o release e confirmar apenas as alterações que pertencem ao release. Todas as outras alterações devem ser feitas no tronco. Você precisaria de dois bancos de dados de desenvolvimento para conseguir isso. Isso seria um problema?

Parece que alguém provavelmente desatualizar-se-á rapidamente. Não? Para um dos meus projetos, estamos no meio de uma revisão maciça do banco de dados, então fizemos uma ramificação para que o desenvolvimento ativo ainda pudesse ocorrer na versão não modificada do banco de dados. No entanto, todos os dias vejo nossa versão ramificada ficando cada vez mais desatualizada, o que não tenho certeza se está tudo bem ou não ... Eu nunca tive que lidar com situações como essa antes.

— 28411 judda

5

Migrações

Um para cima e para baixo, que estão no seu repositório e marcados junto com seu aplicativo.

Você pode até fazer bricolage com sqf flatfiles que modificam seu esquema e atualizam a versão do esquema. Tudo o que você realmente precisa fazer é:

mantenha suas migrações próximas ao código-fonte, elas devem ser versionadas e marcadas juntas
sempre use mudanças gerenciadas (migrações) em todos os ambientes
nunca permita modificações ad-hoc em nenhum ambiente

Bem, você pode fazer alterações no desenvolvimento no desenvolvimento, mas sempre deve surpreender o banco de dados e reconstruí-lo com migrações depois de capturar a alteração.

— dietbuddha
fonte

O que aconteceria se um bug fosse encontrado nos scripts? Você volta ao script sql e atualiza-o?

— judda 29/05

11

Não, você cria uma nova migração (que aumenta a versão do esquema). É assim que você sabe que a correção foi implantada, observando a versão do esquema no banco de dados.

— Dietbuddha 29/05

Obrigado pela ajuda. À primeira vista, isso parece ser uma abordagem muito sólida e semelhante à nossa estratégia de ramificação.

— judda

2

Fonte de controle!

Você não implanta seus binários de desenvolvimento diretamente na produção sem passar por svn / git / p4. Então, por que seus bancos de dados fazem isso sozinhos? Obtenha instâncias privadas para os desenvolvedores testarem suas alterações locais, mas quando precisar ir para o banco de dados de desenvolvimento, ele precisará passar pelos arquivos ddl verificados. Você pode até escrever ferramentas para aplicar essas alterações ddl automaticamente (não conheço nenhuma maneira de fazer isso corretamente).

Depois que você tiver as restrições em torno das alterações do esquema db (não há mais sqlplus -> emitir ddl!) E tiver um controle estrito da conta (sem acesso ddl a todos), isso deverá se tornar mais gerenciável.

— Subu Sankara Subramanian
fonte

11

Infelizmente, nossos bancos de dados são grandes demais para serem repassados entre os desenvolvedores para que as sessões privadas sejam executadas. Além disso, isso realmente não parece inclinar-se para um desenvolvimento mais baseado em equipe, porque, no momento, eu desenvolvo o back-end enquanto converso com as pessoas para o trabalho de interface do usuário que vincula os dois. Eu precisaria começar verificando todas as alterações e depois atualizando-as no banco de dados, o que parece ser um grande aborrecimento.

— 28411 judda

Por que seu banco de dados de desenvolvimento precisa ter o mesmo tamanho que o banco de dados de produção? Eles podem ter o mesmo esquema e você pode até ter uma frota especial de testes de carga com todos os dados, mas os bancos de dados dev locais podem ser pequenos. Isso também evita as preocupações de vazamento de dados etc. - em teoria, os dados do produto não devem afetar o desenvolvimento.

— Subu Sankara Subramanian

Todos os nossos dados são carregados através do nosso processo de carregamento de dados, que processa os arquivos que nos são fornecidos pelo cliente e os transforma nos dados de que precisamos. Portanto, é impossível separarmos os dados dev e prod, pois todas as cargas de dados precisam ser verificadas no desenvolvimento de qualquer maneira. Eu acho que ele não precisa ter o mesmo tamanho, no entanto, precisa de quantidades comparáveis de dados para que os relatórios que criamos gerem informações significativas.

— Judoca 28/05

O banco de dados inteiro não precisa ser replicado. No Oracle, todo usuário tem seu próprio esquema e nós temos um esquema de aplicativo. Crie sinônimos públicos para todos os objetos no esquema do aplicativo. Em seguida, todo usuário pode alterar os objetos (tabelas, SPs) em seu próprio esquema e, se eles se conectarem como eles, seus nomes de objetos serão usados. Para objetos que não estão no esquema, os sinônimos devem ser usados. É assim que trabalhamos.

— softveda

0

Seguindo a sugestão de usar migrações ... talvez use um O / RM que ofereça suporte a migrações como Ruby on Rails e Entity Framework 4.3 O problema com ambas as abordagens, porém, é que uma migração é tudo ou nada. Você não pode (geralmente) selecionar quais migrações são aplicadas como você pode em termos de conjuntos de alterações.

Outra opção viável (se você está na pilha da Microsoft, nunca mencionou a plataforma) é gerenciar seu SQL com as ferramentas de banco de dados do Visual Studio. Ele foi incorporado na refatoração (renomear / remover colunas, etc.) e faz a verificação do modelo. Se, por exemplo, um processo armazenado fizer referência a uma coluna que não está mais lá, ele será informado.

— Michael Brown
fonte