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:
- Os desenvolvedores têm cópia local dos dados para executar o código de desenvolvimento
- Capaz de reverter a estrutura do banco de dados para um conjunto de alterações anterior
- Capaz de separar as novas mudanças no esquema do recurso e as alterações na correção do design do esquema
- 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
#1
acima)- 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
#2
acima)- 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.