Como configurar o processo de desenvolvimento de banco de dados local para uma pequena equipe da web?

fundo

Estou trabalhando na criação de um novo processo de desenvolvimento para uma pequena equipe da Web de cerca de 4 programadores e 4 designers, com o potencial óbvio de aumentar a equipe no futuro. Nosso produto é um aplicativo central que alimenta sites de clientes que também projetamos e hospedamos.

Anteriormente, todos trabalhamos via FTP em um servidor de desenvolvimento, com um único banco de dados de desenvolvimento. "Funcionou" ^* por um tempo, mas estamos caminhando para uma nova direção; portanto, é hora de amadurecer nosso processo.

Usamos o Percona Server 5.5, mas isso deve ser independente do banco de dados, com a idéia de manter os custos baixos.

Objetivos :

Estou pensando em criar um processo de integração contínua (CI) para desenvolvimento de banco de dados com o seguinte em mente:

1. Os desenvolvedores têm cópia local dos dados para executar o código de desenvolvimento
2. Capaz de reverter a estrutura do banco de dados para um conjunto de alterações anterior
3. Capaz de separar as novas mudanças no esquema do recurso e as alterações na correção do design do esquema
4. Capaz de modificar a estrutura do banco de dados localmente para teste

Conceito inicial

Eu esbocei um processo abaixo usando SVN e LiquiBase, embora ele remova completamente #4.

• criar uma ramificação de 'desenvolvimento' a partir do tronco
• servidor db central 'development' sai da ramificação 'development'
• desenvolvedores locais são configurados como escravos do ramo de desenvolvimento (fornece #1acima)
• Os conjuntos de alterações liquibase são confirmados regularmente para a ramificação de desenvolvimento, que executa um gancho pós-confirmação para atualizar o banco de dados central de desenvolvimento (que será aplicado nas máquinas locais em execução como escravas deste servidor de desenvolvimento) (a liquibase fornece #2acima)
• quando os recursos ou as correções de esquema estiverem prontos para o controle de qualidade, o DBA (me) mesclará as alterações apropriadas do ramo de desenvolvimento no tronco. Esse ato criará um script sql para aplicar a um servidor de banco de dados temporário.
• O servidor de temporariedade deve refletir TRUNK, que deve ter a mesma estrutura que Produção, além das alterações que estão no controle de qualidade
• depois de executar o script sql no servidor de temporariedade, faça um controle de qualidade nas alterações.
• Se tudo parecer bom, marque a estrutura com a etiqueta. Isso gerará o script .sql para ser executado em produção manualmente pelo DBA (para horários fora do pico, se necessário)

Esse processo requer que todos os desenvolvedores executem o mesmo ramo 'development', o que significa que existe apenas uma versão do esquema do banco de dados a qualquer momento (não tenho certeza se eu quero isso).

Isso também significa que quaisquer alterações no esquema não podem ser testadas localmente e podem afetar outros desenvolvedores, se não forem feitas corretamente. Em nosso ambiente, os desenvolvedores podem adicionar novas tabelas, mas raramente modificam a estrutura existente. Como o DBA, as correções de design são feitas por mim. Mas a incapacidade de testar correções localmente é a minha maior dificuldade do processo.

Como o processo acima pode ser ajustado para permitir o desenvolvimento local, mantendo uma cópia de dados relativamente atualizada (conforme fornecido pela replicação no meu processo proposto)? Não exijo que os dados estejam atualizados até a última semana.

---

^* Por 'funcionou', quero dizer que bastava, mas era uma PITA.

Gerenciando ambientes

Eu acho que você definitivamente não quer ser forçado a uma única versão do banco de dados. Você tem desenvolvedores suficientes e inevitavelmente terá vários fluxos de trabalho de desenvolvimento e requisitos para aplicar patches no ambiente de produção atual, independentemente dos fluxos de trabalho de desenvolvimento.

Você pode usar o Liquibase ou um processo manual para produzir scripts de patch para atualizar versões. Sugiro começar com um processo manual e usar a ferramenta de comparação de esquema para controle de qualidade nos patches. A sincronização limpa, automatizada e transparente de um banco de dados não trivialmente complexo é um pouco utópica.

Seu modelo de dados central pode ser mantido em qualquer sistema que você desejar. Eu usei tudo, desde ferramentas tediosas de repositório corporativo para criar scripts de tabela. Os scripts de criação de tabela funcionam bem com ferramentas comuns de controle de origem, como o subversion, e nem todas as ferramentas de repositório fazem um bom trabalho de controle de versão.

Tudo o que você usa como seu repositório de modelo de dados mestre, precisa de um mecanismo bastante limpo para implantar um ambiente a partir desse modelo. Ele deve ser estruturado para facilitar a implantação em um ambiente. Você também precisa de um mecanismo para corrigir de uma versão lançada para a próxima.

O que eu fiz

Eu fiz o seguinte no passado quando gerenciava ambientes de desenvolvimento. Não é particularmente de alta tecnologia, mas é passível de controle de versão e compilações automatizadas, facilitando a implantação de um ambiente para uma versão específica, e manter um grande número de ambientes é bastante prático.

Manter um repositório central: pode ser um conjunto de scripts de criação de banco de dados mantidos em sistemas de controle de versão ou um modelo de repositório em uma ferramenta de modelagem de dados. Faça sua escolha. Esse modelo deve ter um mecanismo de construção que permita que um ambiente seja implementado a partir dos scripts sem muita intervenção manual.

Se você tiver muitos dados de referência, precisará de um mecanismo de carregamento. Dependendo de como você deseja fazer isso, você pode mantê-lo em um banco de dados ou em um conjunto de arquivos. A vantagem dos arquivos é que eles também podem ser versionados e rotulados no mesmo sistema de controle de versão da sua base de código. Vários arquivos CSV e scripts do carregador em massa em um repositório de controle de origem podem fazer isso com bastante facilidade.

Uma opção para implantar ambientes de desenvolvimento é fazer backups do banco de dados de produção corrigido para a versão apropriada e disponibilizá-los para que os desenvolvedores restaurem em um ambiente de desenvolvimento.

Facilite a implementação: como qualquer processo de criação de IC, o banco de dados deve ser implantável a partir de um único script. Configure-o para que as conexões com o banco de dados possam ser paramaterizadas ou o script seja independente do local e possa ser executado através da conexão.

Scripts de correção: você precisará avançar e provavelmente reverter scripts de cada versão lançada.

Construir ambientes de teste a partir do modelo de repositório: Isso garante que o desenvolvimento em ambientes fora de sincronia com o repositório seja detectado nos testes.

Teste o processo de implantação: Os scripts de aplicação de patches automatizados, no entanto, eles devem ser testados. As ferramentas de comparação de esquema são muito boas para isso, mesmo que você não as utilize para gerar os scripts de correção.

• Crie um ambiente de referência com o modelo de repositório que você testou

• Crie um ambiente de teste de fumaça com um backup da sua liberação de produção ou uma compilação com base na versão liberada atual.

• Execute o script de correção no ambiente de teste de fumaça.

• Use a ferramenta de comparação de esquema para comparar o ambiente de teste de fumaça com o ambiente de referência. O script de correção deve resultar nos dois bancos de dados idênticos, para que você possa investigar quaisquer diferenças.

O que eu gosto neste processo

Isso é um pouco pesado e foi projetado para implantar em ambientes de produção bastante burocráticos e opacos. No entanto, possui os seguintes pontos fortes:

• Os desenvolvedores podem mexer onde precisam.

• Vários ramos e fluxos de desenvolvimento podem ser acomodados.

• Os próprios scripts de implantação podem ser testados de maneira repetível. Isso é muito útil para encerrar brigas de implantação, como a repetibilidade pode ser demonstrada.

• As ferramentas de comparação de esquema fornecem controle de qualidade na própria implantação.

• Os testes são sempre feitos com relação ao que se espera que seja lançado, e isso trará problemas decorrentes de ambientes fora de sincronia.

• A implantação baseada em modelos de repositório e scripts de correção significa que o lixo não controlado não é migrado acidentalmente dos ambientes de desenvolvimento para a produção.

• Muito do processo pode ser automatizado, embora seja desejável preparar e testar manualmente os scripts de patch de implantação.

• Os ambientes são baratos e fáceis de implantar, sem a necessidade de pular os aros.

• Os desenvolvedores são forçados a criar um sistema que seja passível de um processo simples de compilação e implantação.

• Os desenvolvedores são forçados a aprender tarefas básicas de administração de banco de dados, mas os ambientes de teste e produção são isolados de erros noob.

Como ele atende aos seus requisitos

1. Os desenvolvedores têm cópia local dos dados para executar o código de desenvolvimento.
   
   Os scripts de implantação ou imagens de banco de dados significam que eles podem configurar um ambiente a partir de qualquer versão disponível.

2. Capaz de reverter a estrutura do banco de dados para um conjunto de alterações anterior
   
   Novamente, classificado pelos scripts de implantação. Por meio de DDL ou imagens de backup de banco de dados de teste criadas por meio de um processo controlado, os desenvolvedores podem criar um ambiente para qualquer versão específica que você possui.

3. Capaz de separar as novas mudanças no esquema do recurso e as alterações na correção do design do esquema Os
   
   patches para uma versão comum podem ser mantidos em uma bifurcação separada na árvore svn. Se os backups do banco de dados forem usados ​​como ambientes de referência, eles deverão ser armazenados em algum lugar com a mesma estrutura de pastas que a ramificação dos projetos de controle de origem.

4. Capaz de modificar a estrutura do banco de dados localmente para teste
   
   O processo simples de implantação permite aos desenvolvedores mexer e restaurar facilmente um ambiente em um estado local ou criar um ambiente de referência para fazer comparações e fazer alterações.