Faz tempo que o banco de dados deixou de ser um mero repositório. Hoje em dia os bancos de dados têm muito mais do que isso. Muitas aplicações têm diversos pontos em banco de dados, quando a maior parte da aplicação já não está no banco.

Quando olhamos para o desenvolvimento de software nos dias de hoje, podemos perceber a utilização de diversas práticas e métodos da engenharia como Integração Contínua, Sandboxes, Testes, Versionamento, Refactoring e muito mais. Mas e o banco de dados? Na maioria das vezes não utiliza estas práticas.

A não utilização das práticas de desenvolvimento junto ao banco de dados tem motivos, dentre eles saliente a própria questão cultural. Em muitas empresas a equipe é dividida em desenvolvimento e banco de dados. Logo, quem mexe com Java, .NET, Delphi ou qualquer linguagem por exemplo não é do mesmo grupo das pessoas que lidam com o banco.

Outro fator é paradigmático. Muitas vezes as equipes responsáveis pelo banco de dados estão atreladas a um paradigma que está entranhado há tantos anos que ao
ler o que estou escrevendo só podem ter um resposta emotiva, e não lógica, como diria Tom de Marco.

As práticas e o papel do DBA/AD

A utilização das práticas que mencionei acima não substituem o papel do DBA ou Administrador de Dados. A idéia é que elas vão melhorar a qualidade e a eficiência do seu trabalho. Muitas vezes o processo de administração de banco de dados e schemas é deslocado do versionamento dos fontes da aplicação.

Este cenário é ruim por diversos motivos, além de gerar maior complexidade para gerência de configuração, aumenta muito a carga de comunicação e sincronismo das versões. O ideal é sempre manter os fontes na mesma versão e tag do banco de dados.

Tanto banco, como fontes, fazem parte da aplicação, logo, além de não fazer sentido manter estes artefatos de formas diferentes, seria um risco a mais ao
projeto trabalhar desta forma.

A importância do Versionamento de Banco

Assim como é fundamental versionar os fontes da aplicação em um sistema de controle de versões, como o CVS ou o Subversion, o banco deve ser tratado de forma igual. Infelizmente poucas empresas adotam esta prática.

Quando versionamos o banco, resolvemos parte de um problema, pois assim não perdemos as estruturas do banco, nem a lógica de negócios que se encontra nas triggers, functions e stored procedures. Mas ainda ficam gaps, como por exemplo a aplicação de tags, rollbacks e diffs.

O uso de tags, rollbacks e diffs

Quando temos que lidar com múltiplas versões em desenvolvimento, gerenciar o banco se torna uma tarefa mais complexa ainda. Por exemplo, imagine que duas versões do mesmo produto são desenvolvidas ao mesmo tempo. Entre uma versão e outra, tabelas podem sumir, colunas podem ser modificadas, procedures e functions podem sofrer alterações. Neste cenário, como você sabe que as mudanças são referentes à versão 1.0 ou 2.0?

É uma questão delicada. Você pode usar um controle manual com documentos, por exemplo, mas o melhor seria passar uma tag no banco de dados informando que todas as mudanças neste ponto são referentes à versão 1.0 do software, por exemplo.

Com uma tag, como V1.0, podemos fazer rollback para esta tag, mas como fazer isto na prática? Muitas vezes o que é feito é detonar o banco todo dropando tudo e depois
criando de novo até o ponto da tag, mas sendo feito de forma manual tem um grande esforço.

Com diversos ambientes (Sandboxes) é normal que o banco de produção que pode estar com a versão 2.0 do sistema seja diferente do banco de desenvolvimento que pode estar na versão 2.1. Logo, chega um ponto em que o DBA/AD tem que saber em que versão os bancos estão e o que deve ir para cada banco e o que não deve ir.

Na prática, quanto mais bancos e mais sinôminos e db-links, mais complexa e caótica a coisa é. Já vivi isto na pele, além de gerar muita dor de cabeça para o DBA, gera um desenvolvimento mais vagaroso que esbarra em problemas de schemas incompletos e diferentes entre o desenvolvimento, o teste e a produção.

Neste contexto, realizar um diff é fundamental, mas qual o custo de fazer este diff e gerenciar isto em múltiplos bancos? Adicione a isso o custo de controlar versões, passar tag e realizar rollback. Isso causa, na prática, o fato de que pouca gente utiliza estas práticas em banco de dados e quando utiliza tem um esforço fenomenal para manter isto tudo.

Como encarar as mudanças no banco?

Cada vez mais lidamos com aplicações mais complexas e banco de dados que servem a cada vez mais aplicações. Algumas destas aplicações  usam algum framework de ORM, outras acessam os dados com SQL, logo efetuar uma mudança no banco de dados não é algo tão simples.

Pensando nisto, o Scott Ambler lançou 2 livros de Refactoring de Banco de dados, recomendo muito a leitura destes livros, pois são muito práticos e didáticos. 

Os dois livros são fantásticos. O segundo, Refactoring Databases: Evolutionary Database Design, é perfeito. Ele categoriza os refactoring de banco de dados e nos dá todo um contexto sobre a aplicação do refactoring. Para cada padrão de refactoring, ele nos dá as seguintes informações: motivação, trade offs, mecanismos para atualização de schemas, mecanismos para migração de dados e mecanismos para atualizações de aplicações.

Muitos dos padrões são básicos e todos já conhecemos, como Drop Table, Drop View, Split Table, Move Data, etc…

A ferramenta Liquibase entra em cena…

E se existisse uma ferramenta que possibilitasse o versionamento de banco de dados, a aplicação de atualizações, tags, rollbacks, diffs, geração de documentação das atualizações e ainda aplicação se os padrões de refactoring de banco de dados? Pois existe. Esta ferramenta é o Liquibase.

O Liquibase é um ferramenta open source escrita em Java que possibilita efetuar refactoring em banco de dados além de outras funcionalidades como passar tags, rollback de mudanças, diff de banco de dados e muito mais.

A ferramenta possibilita a utilização destas funcionalides através de:

• Linha de comando (java -jar liquibase.jar %comandos)
• ANT
• Grails
• Spring
• Servlet
• Maven 2

A utilização de Spring permite que aplicações embarcadas possam manipular e controlar o banco internamente. Gosto do fato de que a ferramenta trabalha com ANT e principalmente Maven 2, porque assim podemos criar um projeto java maven 2 que pode ser executado no build contínuo, assim as mudanças da aplicação e banco de dados acontecem juntas.

No próximo artigo, vou mostrar como usar o Liquibase na prática com Maven 2.

Abraços e até a próxima.