Oi, pessoal! Hoje comecei a estudar sobre migrations de banco de dados. Achei o assunto super relevante e resolvi escrever um artigo para compartilhar com vocês um pouco do que descobri em meus estudos. Este texto é uma introdução à migrations e não tem a pretensão de explorar o tema em mínimos detalhes, mas sim despertar a curiosidade sobre o conceito de banco de dados evolutivo.

Com a popularização das metodologias ágeis, a arquitetura evolutiva tornou-se uma das prioridades no desenvolvimento de software. Os métodos ágeis buscam permitir a adaptação a mudanças ao decorrer do projeto, uma vez que os requisitos podem ser frequentemente alterados e temos que estar preparados para lidar com esta dinamicidade. Esta necessidade aplica-se também ao banco de dados, e é neste contexto que destaca-se a importância das migrations.

Migrations são um mecanismo de gestão de mudanças de banco de dados que permitem o versionamento e a abstração na modelagem do banco. Com o uso de migrations, é possível manter um registro das alterações realizadas no banco de dados ao longo do tempo, tornando-se possível a aplicação de uma abordagem evolutiva na modelagem do projeto. Algumas das ferramentas mais utilizadas para migrations de banco de dados são Flyway, dbdeploy e MyBatis.

Aplicando migrations no projeto

Para aplicar este mecanismo, o primeiro aspecto que temos que ter em mente é que todas as alterações do banco de dados são migrations. Logo, nesta abordagem, não são utilizadas ferramentas de edição de esquema como o Workbench para alterar o banco de dados. Cada mudança deve ser capturada durante o desenvolvimento e mantida como um artefato de primeira classe que poderá ser testado e implantado na produção, da mesma forma que as alterações feitas no código da aplicação. Ainda, cada mudança no banco de dados deve ser representada como um script de migração de banco de dados cuja versão é controlada.

Identificação de migrations

Cada migration deve receber um número de sequência, que atua como um identificador único, e uma breve descrição das alterações feitas, com as palavras separadas por underscores (_). Ao criar uma migration, devemos inserir o SQL em um arquivo de texto dentro de uma pasta de migrations, no repositório do projeto. Devemos verificar o arquivo da pasta migrations que possui o número mais alto em sua identificação, e usar o número sucessor a este para identificar a nossa própria migration.

Exemplo:

Se o arquivo de número mais alto encontrado na pasta estiver nomeado como 0007_add_insurance_value_to_equipment_type.sql, então a nossa migration poderá ser nomeada como 0008_data_location_equipment_type.

Rastreamento de migrations

Para rastrear as migrations do banco de dados, usamos uma tabela changelog. Essa tabela geralmente é criada e atualizada automaticamente pelos frameworks de migração de banco de dados. Dessa forma, é possível obter o relatório de quais migrations estão sincronizadas com o banco de dados, como demonstrado no exemplo abaixo:

Instâncias separadas de banco de dados

Ao trabalhar com projetos de bancos de dados ágeis, cada membro da equipe tem a sua própria instância de banco de dados, a qual pode modificar livremente sem interferir o trabalho de outras pessoas do time. Posteriormente, quando estiverem prontas, as alterações podem ser enviadas e compartilhadas entre os membros do projeto.

As diferentes alterações devem ser integradas com frequência para garantir que o projeto principal esteja sempre atualizado, o que ajuda a minimizar possíveis conflitos. A recomendação é que cada membro da equipe integre suas alterações ao projeto principal pelo menos uma vez ao dia. A utilização de Integração Contínua (CI) é uma ótima maneira de tornar este processo mais eficiente, e algumas das ferramentas utilizadas para CI incluem GoCD, Snap CI, Jenkins, Bamboo e Travis CI.

Localização das migrations no projeto

Por convenção, geralmente é possível encontrar as migrations do projeto seguindo o seguinte caminho:

src > main > resources > db > migration

Com a aplicação destes princípios, o banco de dados do projeto passa a ter um caráter evolutivo, que o torna mais flexível a mudanças, como previsto pelas metodologias ágeis. O banco de dados pode evoluir tanto quanto o código da aplicação, permitindo colocar o software em produção mais cedo.