Gerenciando e testando seu banco de dados com Liquibase e JUnit

Para quem já programa há algum tempo sabe que gerenciar a estrutura e os dados do banco de dados de uma aplicação é uma das partes mais complicadas e sujeitas a erros em um processo de desenvolvimento. A fim de mitigar esse problema, foram criadas diversas soluções com o intuito de deixar essa etapa mais simples, cada uma com suas vantagens e desvantagens.

Uma dessas opções é compartilhar a responsabilidade da gestão do banco com outros profissionais, como os DBAs. Nesses casos, quando o desenvolvedor percebe que precisará criar uma nova coluna em uma tabela, ele prepara o comando SQL e o envia para o DBA, que irá validar e, às vezes, até otimizar o comando, fazendo a gestão de todos os comandos que deverão ser executados no momento da entrega de uma nova release do sistema. Uma das vantagens dessa maneira de trabalhar é que os desenvolvedores ficam mais focados no código e os DBAs podem gerenciar todo o processo de mudança na base de dados, mas ao mesmo tempo exige um maior alinhamento entre as equipes na entrega de uma release, pois também serão os DBAs que executarão todos os scripts necessários antes que os desenvolvedores subam a nova versão para produção, que espera encontrar aquela nova coluna na base de dados.

Como sincronizar o trabalho de diferentes equipes pode ser muito custoso e envolver muitas atividades manuais, alguns desenvolvedores tentaram automatizar a atualização das estruturas das tabelas do banco de dados criando e melhorando frameworks já existentes, como o Hibernate. Além de controlar as consultas e inserções nas tabelas que são realizadas pela aplicação, o Hibernate também pode atualizar a estrutura dessas tabelas sem a necessidade de você criar e executar scripts SQL. Isso é feito colocando o valor update na propriedade hibernate.hbm2ddl.auto, o que faz o framework alterar as estruturas da base de acordo com as classes de entidade do projeto no momento em que a aplicação estiver sendo iniciada. Caso uma nova tabela, ou coluna, precise ser criada, o Hibernate executa os comandos necessários para isso. O problema dessa funcionalidade é que se a aplicação começar a ficar lenta e um DBA precisar otimizar algo, o Hibernate pode não validar essas otimizações e, às vezes, até desfazê-las, dependendo de como estão suas configurações.

Ao final, essas opções que discutimos ficam, de certa forma, nos extremos de como é possível gerenciar um banco de dados: na primeira opção, a gestão é completamente manual; já na segunda, totalmente automatizada, o que dificulta a implantação de otimizações que a ferramenta talvez não seja capaz de realizar. Diante disso, será que existe um jeito de unir as vantagens das duas em uma só solução?

Encontrando o meio-termo: o Liquibase

Vamos imaginar uma maneira um pouco diferente para gerenciar uma base de dados. Que tal os desenvolvedores continuarem criando os scripts SQL do banco, só que de uma forma mais padronizada e estruturada, permitindo que alguma ferramenta os execute automaticamente no momento da entrega de uma release? E, além disso, mantermos os DBAs validando e otimizando esses scripts? Essa opção agora é uma realidade, pois já existe um framework que faz esse meio-termo entre a automatização e as atividades manuais: o Liquibase.

De forma simples, podemos definir o Liquibase como uma biblioteca de código aberto que tem como objetivo gerenciar as alterações realizadas no banco de dados. Criado em 2006, ele pode se integrar aos principais gerenciadores de projetos, como o Maven, Gradle e Ant, facilitando bastante sua utilização. Essa biblioteca possui diversos comandos que permitem realizar a gestão do banco, como fazer um rollback até determinada alteração, atualizar a base executando todos os scripts que ainda faltam e até criar um arquivo com toda a estrutura atual do banco de dados. O Liquibase consegue, ainda, simultaneamente, gerenciar outra base de dados, só que essa sendo exclusiva para testes. Assim, a criação e execução de testes integrados com o banco se torna uma tarefa menos complicada.

Um dos diferenciais dessa solução é que ela suporta arquivos de script nos formatos XML, YAML, JSON ou SQL, sempre utilizando o conceito de changeSets, que nada mais é do que um conjunto de comandos que o Liquibase deve executar na base de dados como, por exemplo, um comando de criação de tabela seguido por outro de inserção de um registro. Nesse contexto, um ou mais conjuntos de comandos, ou changeSets, podem ser colocados em um mesmo arquivo, chamado de changeLog. Para isso, no entanto, cada changeSet precisa ter um identificador, preferencialmente único, para que o Liquibase possa identificar quais conjuntos de comandos já foram ou precisam ser executados no banco.

Quando o Liquibase é executado, ele verifica todos os changeSets existentes nos arquivos de changeLog e começa a aplicá-los na base de dados, pela ordem do nome dos arquivos. A gestão de quais changeSets foram executados acontece na tabela "