Quais são os principais problemas no gerenciamento do banco de dados

O gerenciamento e a organização de dados impõem um conjunto específico de problemas para os processos de teste e implantação por duas razões.

Na maioria dos casos, quando fazemos implantação de novo código, podemos apagar a versão anterior e substituí-la completamente por uma nova cópia. Dessa forma, podemos ter certeza de nossa posição inicial. Essa opção é viável para gerenciar dados em alguns casos limitados, mas, para a maioria dos sistemas do mundo real, essa abordagem é inviável.

Quando o sistema for entregue em produção, os dados associados a ele irão crescer e agregarão valor significativo por si só́. Na verdade, possivelmente será́ a parte mais valiosa de seu sistema. Isso apresenta problemas quando precisamos modificar tanto sua estrutura quanto seu conteúdo.

Conforme sistemas crescem e evoluem, é inevitável que tais modificações sejam necessárias, então precisamos de mecanismos que permitam que mudanças sejam feitas de forma a minimizar a interrupção e maximizar a confiabilidade da aplicação e seu processo de implantação. A chave para isso é automatizar o processo de migração do banco de dados.

Já existem diversas ferramentas que permitem a automação da migração de dados de forma relativamente simples, permitindo que esses scripts sejam incorporados ao processo automatizado de implantação.

Essas ferramentas também permitem que você versione seu banco de dados e migre-o de uma versão para qualquer outra. Isso tem a vantagem de desacoplar o processo de desenvolvimento do processo de implantação – você pode criar uma migração para cada mudança necessária no banco de dados, mesmo que não faça a implantação de cada mudança de esquema independentemente.

Isso também significa que seus administradores de banco de dados (DBAs) não precisam de um grande plano inicial – eles podem trabalhar de forma incremental conforme a aplicação evolui.

Outra área importante é o gerenciamento de dados de teste. Ao realizar testes de aceitação ou testes de capacidade (ou até mesmo testes unitários), a opção padrão para muitos times é usar uma cópia dos dados de produção. Isso cria problemas por diversas razões (não apenas o tamanho do conjunto de dados), e iremos oferecer estratégias alternativas aqui..

Assim como qualquer mudança em seu sistema, qualquer mudança em qualquer banco de dados usado como parte de seus processos de compilação, implantação, teste e entrega deve ser gerenciada por um processo automatizado. Isso significa que a inicialização do banco de dados e todas as migrações necessárias devem ser capturadas como scripts e armazenadas no sistema de controle de versões.

Deve-se poder usar esses scripts para gerenciar todos os bancos de dados usados em seu processo de entrega, seja para criar um banco de dados local para um desenvolvedor que está trabalhando em novo código, para atualizar um ambiente de teste de integração do sistema (SIT) para testadores, ou para migrar o banco de dados de produção como parte do processo de entrega.

Obviamente, o esquema de seu banco de dados deve evoluir junto com a aplicação. Isso representa um problema, pois é importante que o banco de dados tenha um esquema correto para determinada versão da aplicação. Por exemplo, ao fazer implantação para staging, é essencial podermos migrar o banco de dados de staging para o esquema correto que funcione com a versão da aplicação que está sendo implantada.

Um gerenciamento cuidadoso dos scripts permite que isso seja possível, “Mudanças incrementais”. Finalmente, seus scripts de banco de dados devem ser usados como parte do processo de integração contínua. Enquanto os testes unitários não devem, por definição, precisar de um banco de dados para rodar, qualquer tipo de teste de aceitação que faça sentido, rodando contra uma aplicação que use um banco de dados, precisará de um banco de dados corretamente inicializado.

Assim, parte do processo de preparação do teste de aceitação deve criar um banco de dados com um esquema correto, que funcione com a versão mais recente da aplicação, e carregá-lo com qualquer tipo de dados de teste necessários para rodar os testes de aceitação. Um procedimento similar pode ser usado para estágios mais avançados do pipeline de implantação.

Um aspecto extremamente importante para nossa abordagem de entrega é a habilidade de reproduzir um ambiente, juntamente à aplicação que roda nele, de forma automatizada. Sem essa habilidade, não podemos ter certeza de que o sistema irá se comportar da maneira esperada.

Esse aspecto da implantação de banco de dados é o mais simples de acertar e de manter conforme sua aplicação muda durante o processo de desenvolvimento. Quase todo sistema de gerenciamento de dados dá suporte à inicialização de um armazém de dados, incluindo esquema e credenciais de usuário, a partir de scripts automatizados.

Então, a criação e manutenção de um script de inicialização do banco de dados é um ponto de partida simples. Seu script deve primeiramente criar a estrutura do banco de dados, instâncias, esquemas, e assim por diante, e então preencher as tabelas do banco de dados com qualquer dado de referência necessário para que sua aplicação seja inicializada.

Este script, assim como todos os outros scripts envolvidos na manutenção do banco de dados, deve obviamente ser armazenado no sistema de controle de versão, juntamente com o código-fonte.

Para alguns projetos simples, isso pode ser suficiente. Para projetos em que o conjunto de dados operacional é de alguma forma transitório – ou quando ele é predefinido, como sistemas que usam o banco de dados em tempo de execução como um recurso somente para leitura – apenas apagar a versão anterior e substituí-la por uma nova cópia, recriada a partir do que está armazenado no controle de versões, é uma estratégia simples e eficaz. Se isso é o suficiente para você, faça isso!

Em sua forma mais simples, o processo de implantação de um novo banco de dados é:

Fique por dentro de nossos conteúdos se cadastrando na nossa newsletter semanal! Clique aqui!