Como gerenciar e versionar o seu banco de dados de forma simples e prática?

E se fosse possível aplicar algumas técnicas de CD/CI no seu banco de dados? E se fosse possível versionar as alterações que são feitas para o seu banco? Bom, isso e outras coisas são possíveis sim, e eu vou te mostrar como.

Quero compartilhar com vocês uma experiência que eu tive com uma ferramenta que me tirou uma tonelada de problemas das costas. Essa ferramenta é o Liquibase. Pra quem não conhece, é uma biblioteca open-source para banco de dados que permite gerenciar e versionar o seu banco através de esquemas, que podem ser construídos em diversos formatos 一 SQL, JSON, YAML ou XML… aí cabe a você escolher o que mais te agrada.

Antes de falar de todas as facilidades que o Liquibase te permite, eu vou contar qual foi a minha pedra no sapato. No projeto em que aplicamos a ferramenta, trabalhamos com quatro ambientes e, para cada ambiente, um banco onde os dados muitas vezes não são os mesmos, já que alguns ambientes recebem operações e inputs dos clientes. Os ambientes são: produção, homologação, desenvolvimento e um ambiente local. Para o ambiente local, utilizamos um docker com uma imagem PostgreSQL. Como esse ambiente é usado para desenvolvimento imediato, quando aparecia alguma falha, podíamos apagar o banco e restaurar com o backup mais recente. À medida que vamos subindo nas categorias de criticidade dos ambientes, vai sendo exigida mais atenção e quando falamos de homologação e produção, as coisas são bem mais delicadas.

No começo da construção do sistema, sempre que uma nova funcionalidade era aceita para ser desenvolvida, alguns detalhes também tinham que ser levados em conta para serem integrados na aplicação. Esses detalhes poderiam ser uma coluna a mais no banco, alterar o tipo de uma outra coluna, uma tabela nova, uma inserção… são detalhes que podiam acabar mexendo na estrutura do banco. A minha questão estava bem aí: eu precisava propagar essas alterações para todos os bancos nos diferentes ambientes, garantindo a consistência dos dados de forma prática e segura.

Depois que conheci o Liquibase, esse problema foi resolvido. Só foi necessário configurar a biblioteca na aplicação (no meu caso, a aplicação está em Java e utilizamos Maven) e criar um “script”. Com poucas e simples linhas de código, era possível determinar quais as alterações e ambientes eu queria que as operações fossem realizadas. Depois disso, só era necessário rodar a aplicação que as mudanças eram executadas automaticamente. Claro que o trabalho de garantir que as modificações estivessem corretas continuou, mas agora eu tinha a possibilidade de testá-las localmente, de uma forma muito mais prática. Além disso, a minha preocupação em analisar cada banco, para garantir a consistência das estruturas, não existia mais.

Como o Liquibase funciona?

Antes de começar a entender como funciona o Liquibase, é importante conhecer duas definições: databasechangeLog e changeSet. Explicando de forma mais resumida, o primeiro se refere ao conjunto de ações que serão executadas em um único script. Já o segundo é o elemento mínimo de mudanças; um changeSet contém uma operação de alteração do banco.Então vamos ao que interessa: código e mão na massa! Para os exemplos a seguir, utilizei a formatação do Liquibase em XML. Vou explicar alguns pontos em cada trecho do código que acredito serem importantes.

tabela código Liquibase Já na na declaração do changeSet, têm alguns detalhes das propriedades que valem uma explicação. São elas author, context e id.

  • author: é útil para times em que mais de uma pessoa vão estar trabalhando no desenvolvimento das funcionalidades. A identificação do autor ajuda para os casos em que aconteça algum erro na execução da aplicação, e o autor do código pode ser procurado para sanar alguma dúvida.
  • context: é basicamente um rótulo. Você pode criar diferentes contextos para os changesets e, ao executar a aplicação, sinalizar qual contexto deseja que seja executado, simplesmente passando como um parâmetro. Isso pode ser interessante inclusive para o caso em que se deseja realizar uma mudança para o banco de algum ambiente em específico;
  • id: como o próprio nome já diz é um identificador. É interessante salientar que, mesmo para changelogs diferentes, é importante colocar ids diferentes, pois facilita na localização do changeset;

Neste exemplo, a ação demonstrada foi a de criação de uma tabela e o banco de dados que foi utilizado como base para montar os scripts foi em PostgreSQL. Nesse link, você encontra uma tabela onde pode verificar para quais bancos de dados o Liquibase oferece suporte.

Liquibase usa uma certa abstração para tratar dos diferentes tipos de dados. Quando é criada uma tabela através dos scripts, é importante verificar qual é a representação dos tipos das colunas que você deseja criar. Elas podem variar um pouco dependendo de qual tecnologia você esteja utilizando para o seu banco. Na tabela abaixo, fica fácil de identificar o mapeamento que é feito. Essa tabela é para a versão 3.6.x do Liquibase; caso você esteja utilizando outra versão, consulte a documentação.

tabela código Liquibase Outras duas propriedades que eu acho essenciais no Liquibase são a preConditions e a rollBack. Essas duas deixam o changeSet muito mais seguro e robusto. Para as operações que alteram o banco, é muito importante realizar uma validação para saber se, ao ser executada, não vai quebrar nenhuma outro componente. Isso torna a propriedade preConditions fundamental, pois, se a condição imposta for respeitada, você pode escolher se quer executar ou não o restante do changeSet. Caso algum erro ocorra durante a operação, a possibilidade de apagar a alteração que tenha sido malsucedida também torna o rollBack uma propriedade perfeita. No exemplo do script logo acima, eu insiro uma nova linha na tabela users: se acontecer algum erro, o Liquibase executa o rollBack, que apaga a linha caso ela tenha sido inserida.

Com as inúmeras propriedades que o Liquibase já disponibiliza para facilitar a sua vida, até mesmo quem não entende muito de SQL pode se virar muito bem. As opções vão desde operações como alterar uma coluna, criar uma tabela, criar um index, até mesmo fazer um merge de colunas. Caso você entenda de SQL, melhor ainda! Além de ser mais fácil para criar os changesets, também existe uma propriedade onde você pode implementar as suas próprias queries. Então se você precisa de uma busca ou execução mais complexa, não vai ter problema nenhum. A lista de todas as operações possíveis que você pode realizar no Liquibase pode ser conferida clicando aqui.

Bom, isso é tudo pessoal! Espero que tenham curtido o Liquibase e que ele possa ajudar nos seus projetos. Até o próximo post.

Fonte: Blog Neurolake

Compartilhar no facebook
Compartilhar no whatsapp
Compartilhar no linkedin
Compartilhar no telegram
Compartilhar no email

Posts Relacionados

  • RECIFE

+ 55 81 3312-2740

Rua Alfândega, 35 – 4º andar
Shopping Paço Alfândega
Recife – PE- Brasil​
CEP: 50030-030

  • SÃO PAULO

+ 55 11 3076-7900

Rua Joaquim Floriano, 72
12º andar – cj. 121
Itaim Bibi – São Paulo
SP – Brasil
CEP: 04534-000
  • contato@neurotech.com.br
SOLUÇÕES
NEUROTECH
  • RECIFE

+ 55 81 3312-2740

Rua Alfândega, 35 – 4º andar
Shopping Paço Alfândega
Recife – PE- Brasil​
CEP: 50030-030

  • SÃO PAULO

+ 55 11 3076-7900

Rua Joaquim Floriano, 72
12º andar – cj. 121
Itaim Bibi – São Paulo
SP – Brasil
CEP: 04534-000