Refactoring de Banco de Dados com Liquibase: Parte 1 Conceitutal
Faz tempo que o banco de dados deixou de ser um mero repositório. Hoje em dia os bancos de dados tem muito mais do que um mero repositório. Muitas aplicações tem diversos pontos em banco de dados, quando a maior parte de aplicação já não esta 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 Continua, 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 é dividia em desenvolvimento e banco de dados, logo que mexe com Java, .NET, Delphi ou qualquer linguagem por exemplo não é do mesmo grupo das pessoas que lidam com o banco.
Outro fator é o paradigma, muitas vezes as equipes responsáveis pelo banco de dados estão atreladas a um paradigma que está entranhado a 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 a cima não substituem o papel do DBA ou Administrador de Dados. A idéia é que elas vão melhorar a qualidade 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, aumente 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 quanto fontes fazem parte da aplicação, logo além de não ter 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 e bem como 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 2 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 a versão 1.0 ou 2.0 ?
Pois é uma questão delicada, você por 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 a versão 1.0 do software por exemplo.
Com uma tag, exemplo 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 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 sinominos e db-links, mais complexa e caótica a coisa é. Ja 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, teste e produção.
Neste contexto por realizar um diff é fundamental, mas qual o custo de fazer este diff e gerenciar isto em múltiplos bancos? Adicione o custo de controlar versões, passar tag e realizar rollback? É isso acareta que na prática 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, estas aplicações algumas 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 livro(Refactoring Databases: Evolutionary Database Design) é perfeito. Neste livro ele categoriza os refactoring de banco de dados e nos da todo um contexto sobre a aplicação do refactoring. Para cada padrão de refactoring ele nos da 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 nos já conhecemos como por exemplo: Drop Table, Drop View, Split Table, Move Data, etc...
A ferramenta Liquibase entra em cena...
Se existisse uma ferramenta que possibilita-se 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:
No próximo post vou mostrar como usar o Liquibase na prática com Maven 2.
Abraços e até a próxima.
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 Continua, 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 é dividia em desenvolvimento e banco de dados, logo que mexe com Java, .NET, Delphi ou qualquer linguagem por exemplo não é do mesmo grupo das pessoas que lidam com o banco.
Outro fator é o paradigma, muitas vezes as equipes responsáveis pelo banco de dados estão atreladas a um paradigma que está entranhado a 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 a cima não substituem o papel do DBA ou Administrador de Dados. A idéia é que elas vão melhorar a qualidade 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, aumente 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 quanto fontes fazem parte da aplicação, logo além de não ter 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 e bem como 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 2 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 a versão 1.0 ou 2.0 ?
Pois é uma questão delicada, você por 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 a versão 1.0 do software por exemplo.
Com uma tag, exemplo 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 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 sinominos e db-links, mais complexa e caótica a coisa é. Ja 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, teste e produção.
Neste contexto por realizar um diff é fundamental, mas qual o custo de fazer este diff e gerenciar isto em múltiplos bancos? Adicione o custo de controlar versões, passar tag e realizar rollback? É isso acareta que na prática 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, estas aplicações algumas 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 livro(Refactoring Databases: Evolutionary Database Design) é perfeito. Neste livro ele categoriza os refactoring de banco de dados e nos da todo um contexto sobre a aplicação do refactoring. Para cada padrão de refactoring ele nos da 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 nos já conhecemos como por exemplo: Drop Table, Drop View, Split Table, Move Data, etc...
A ferramenta Liquibase entra em cena...
Se existisse uma ferramenta que possibilita-se 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
No próximo post vou mostrar como usar o Liquibase na prática com Maven 2.
Abraços e até a próxima.
