Fundo
Estou trabalhando na criação de um novo processo de desenvolvimento para uma pequena equipe web de cerca de 4 programadores e 4 designers, com o óbvio potencial de crescimento da equipe no futuro. Nosso produto é um aplicativo central que alimenta sites de clientes que também projetamos e hospedamos.
Anteriormente, todos trabalhávamos 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, então é hora de amadurecer nosso processo.
Usamos o Percona Server 5.5, mas deve ser independente do banco de dados, com a ideia 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 uma 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 novas alterações de esquema de recurso versus alterações de correção de design de esquema
- Capaz de modificar a estrutura do banco de dados localmente para teste
Conceito inicial
Esbocei um processo abaixo usando SVN e LiquiBase, embora remova completamente #4.
- crie uma ramificação de 'desenvolvimento' a partir do tronco
- servidor db 'desenvolvimento' central é executado fora do ramo 'desenvolvimento'
- desenvolvedores locais são configurados como escravos para o ramo de desenvolvimento (fornece
#1acima)- Os conjuntos de alterações do liquibase são confirmados regularmente no ramo de desenvolvimento, que executa um gancho pós-confirmação para atualizar o banco de dados de desenvolvimento central (que será transferido para as máquinas locais executando como escravos para este servidor de desenvolvimento) (o liquibase fornece
#2acima)- quando os recursos ou correções de esquema estiverem prontos para ir para o controle de qualidade, o DBA (eu) mesclará as alterações apropriadas da ramificação de desenvolvimento no tronco. Este ato criará um script sql para aplicar a um servidor de banco de dados temporário.
- O servidor Staging deve refletir o TRUNK, que deve ter a mesma estrutura da Produção, mais as alterações que estão no QA
- depois de executar o script sql no servidor de teste, faça algum controle de qualidade nas alterações.
- Se tudo parecer bom, MARQUE a estrutura. Isso irá gerar o script .sql para ser executado em produção manualmente pelo DBA (para horários fora de pico, se necessário)
Esse processo requer que todos os desenvolvedores executem a mesma ramificação de 'desenvolvimento', o que significa que há apenas uma versão do esquema do banco de dados a qualquer momento (não tenho certeza se 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 DBA, as correções de design são feitas por mim. Mas a incapacidade de testar as correções localmente é meu maior problema no processo.
Como o processo acima pode ser ajustado para permitir o desenvolvimento local, mantendo uma cópia relativamente atualizada dos dados (conforme fornecido pela replicação em meu processo proposto)? Não exijo que os dados estejam atualizados até a última semana.
* Por 'funcionou', quero dizer que bastou, mas foi um PITA.
Gerenciando ambientes
Acho que você definitivamente não quer ser forçado a usar 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 ao ambiente de produção atual independente dos fluxos de trabalho de desenvolvimento.
Você pode usar o Liquibase ou um processo manual para produzir scripts de patch para atualizar as 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 de sua preferência. Eu usei de tudo, desde ferramentas tediosas de repositório corporativo até criar scripts de tabela. Criar scripts de tabela funcionam bem com ferramentas comuns de controle de código-fonte, como subversion, e nem todas as ferramentas de repositório fazem um bom trabalho de controle de versão.
O que quer que você use como seu repositório de modelo de dados mestre, você precisa de um mecanismo razoavelmente limpo para implantar um ambiente desse modelo. Ele deve ser estruturado de forma que as implementações em um ambiente sejam fáceis. 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 estava gerenciando ambientes de desenvolvimento. Não é particularmente de alta tecnologia, mas é passível de controle de versão e compilações automatizadas, por isso facilita a implantação de um ambiente para uma versão específica e a manutenção de um grande número de ambientes é bastante prática.
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 compilação que permita que um ambiente seja implantado a partir dos scripts sem muita intervenção manual.
Se você tiver muitos dados de referência, precisará de um mecanismo de carregamento para eles. Dependendo de como você deseja fazer isso, você pode manter isso em um banco de dados ou em um conjunto de arquivos. A vantagem dos arquivos é que eles também podem ser versionados e rotulados a partir do mesmo sistema de controle de versão de sua base de código. Vários arquivos CSV e scripts de carregamento 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 implantação: como qualquer processo de criação de CI, o banco de dados deve ser implantado a partir de um único script. Configure-o para que as conexões de banco de dados possam ser parametrizadas ou o script seja independente do local e possa ser executado apenas por meio da conexão.
Scripts de correção: você precisará avançar e provavelmente reverter scripts de cada versão lançada.
Crie ambientes de teste a partir do modelo de repositório: Isso garante que o desenvolvimento em ambientes que não estão sincronizados com o repositório seja capturado no teste.
Teste o processo de implantação: os scripts de aplicação de patches automatizados, independentemente de como são criados, devem ser testáveis. As ferramentas de comparação de esquema são muito boas para isso, mesmo que você não as use para gerar os scripts de correção.
Crie um ambiente de referência com a compilação do modelo de repositório que você testou
Crie um ambiente de teste de fumaça com um backup de sua versão de produção ou uma compilação baseada na versão lançada 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 patch deve resultar em 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 implantação em ambientes de produção bastante burocráticos e opacos. No entanto, tem os seguintes pontos fortes:
Os desenvolvedores podem mexer onde precisam.
Várias ramificações 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, pois a repetibilidade pode ser demonstrada.
As ferramentas de comparação de esquema fornecem controle de qualidade na própria implantação.
O teste é sempre feito em relação ao que se espera que seja lançado, e isso detectará 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 descontrolado não é migrado acidentalmente dos ambientes de desenvolvimento para a produção.
Muito do processo pode ser automatizado, embora muitas vezes seja desejável preparar e testar os scripts de patch de implantação manualmente.
Os ambientes são baratos e fáceis de implantar sem ter que passar por cima de obstáculos.
Os desenvolvedores são forçados a criar um sistema que seja passível de um processo simples de construçã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 de novatos.
Como ele aborda seus requisitos
Os desenvolvedores têm uma 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.
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ê tenha.
Capaz de separar novas alterações de esquema de recurso versus alterações de correção de design de esquema
Patches para uma versão comum podem ser mantidos em uma bifurcação separada na árvore svn. Se os backups de banco de dados forem usados como ambientes de referência, eles precisam ser armazenados em algum lugar com a mesma estrutura de pastas que a ramificação dos projetos de controle de origem.
Capaz de modificar a estrutura do banco de dados localmente para teste
O processo de implantação simples permite que os desenvolvedores mexam e restaurem facilmente um ambiente para um estado local ou criem um ambiente de referência para fazer comparações e conjuntos de alterações.