Após a leitura desse artigo, será
possível construir uma base de dados versionada em paralelo a qualquer sistema
usando a ferramenta de versionamento LiquiBase. O tema é útil para o
profissional de banco de dados que possua uma ou mais bases de desenvolvimento,
homologação e produção e que precise, constantemente, alterar versões dessas
bases para que seja possível adequá-las a um sistema que sofra constantes
modificações.
Levando-se em consideração o modelo sequencial (ou modelo em cascata) de desenvolvimento de software, no qual a concepção de um sistema é vista como um fluir constante para frente, através das fases de análises de requisitos, projeto, implementação, testes, integração e manutenção, mudanças causam problemas significativos, uma vez que todo trabalho é iniciado.
Em contrapartida, para lidar melhor com as constantes alterações de requisitos de sistema, surgiu uma nova geração de metodologias de desenvolvimento de software – as metodologias ágeis.
Uma das principais características dessas metodologias é a predisposição para lidar com mudanças. Elas buscam aceitar as modificações, controlando-as, em quaisquer fases do projeto até o fim do desenvolvimento.
A fim de aceitar o desafio de lidar com variações constantes no projeto de construção de um sistema, é necessário adotar um pensamento diferenciado. Em vez de conceber o design como uma fase isolada e, em grande parte, concluída antes do início do desenvolvimento, é preciso olhar para ele como um processo contínuo que intercala com a construção até o momento da entrega do software. Esse é o principal contraste entre o design planejado, como o da metodologia sequencial, e o design evolutivo das metodologias ágeis.
Apesar dessas novas técnicas terem crescido em uso e interesse, uma das maiores questões é como fazer o trabalho de design evolutivo para banco de dados.
É necessário que a estrutura do SGBD evolua em conjunto com o sistema para que se tenha sucesso na implementação dos métodos ágeis. E é sobre isso que esse artigo trata, sobre conceitos e técnicas de implementar a construção evolutiva da estrutura de banco de dados.
Colaboração contínua
Inicialmente, para que a ideia de design de banco de dados evolutivo possa funcionar e fluir bem onde ela estiver sendo aplicada, é necessário que algumas medidas sejam adotadas. Uma delas é uma colaboração contínua e irrestrita entre todo o time de desenvolvimento.
Não podem existir barreiras para essa comunicação. Em vez de decisões tomadas em reuniões formais, por exemplo, é preciso que ocorram conversas abertas entre todos os profissionais de forma a facilitar a comunicação.
Outra medida consiste em fazer com que cada atividade executada por um programador que afete, de alguma forma, a estrutura DDL ou DML do banco de dados seja feita em colaboração com o administrador de dados.
Assim, como o desenvolvedor sabe acerca da precisão de uma nova funcionalidade, o responsável pelo SGBD possui uma visão global dos dados e da estrutura do banco.
Dessa forma, será possível descobrir de que forma essa nova implementação irá afetar o esquema de banco de dados e qual a melhor forma de executá-la.
Instâncias de banco de dados - SandBox
O conceito de metodologia ágil reconhece que as pessoas aprendem coisas por tentar executá-las. Na programação podemos ver que os desenvolvedores experimentam formas de fazer determinada característica, podendo assim escolher uma melhor forma de implementá-la.
Com a base de dados não deve ser diferente. É preciso conceder a cada um dos desenvolvedores um banco de dados próprio (conhecido como sandbox). Dessa maneira, assim como na programação, o desenvolvedor poderá usar a imaginação em seu próprio ambiente, mexendo na estrutura da base de dados como bem quiser, sem que essas variações afetem alguém de alguma forma.
Muitos especialistas DBAs veem essa opção como muito difícil de funcionar na prática. Porém, observa-se que sim, é possível trabalhar com inúmeras bases. Mas para isso é essencial possuir ferramentas que manipulem as bases tão facilmente quanto se manipulam arquivos.
Banco de dados central - Master
Embora os desenvolvedores possam realizar as mudanças de forma distribuída, é importante unir essas diferentes mudanças em um único lugar novamente. Ou seja, para aplicar o conceito de banco de dados evolutivo é necessário que exista um banco de dados central ou master que integre todos essas alterações de estrutura de banco feita por cada um dos programadores.
A cada dia uma foto do banco de dados central é feita e a sua imagem é implantada em cada uma das sandbox de cada um dos desenvolvedores. E ao final de cada dia, essas mudanças são reintegradas à base master.
É claro que o DBA deve estar ciente de todas as mudanças feitas pelos desenvolvedores. Por isso foi dito anteriormente sobre a importância de uma comunicação contínua e sem barreiras.
É importante que as integrações das sandbox com o banco de dados central sejam feitas constantemente, pois fazer várias pequenas alterações em um ambiente é mais fácil do que executar uma única grande mudança.
Refatorações de banco de dados
Toda e qualquer alteração feita na base de dados é denominada refatoração. Essa técnica de refatoração do SGBD torna-se complexa porque no banco existem três diferentes mudanças que ora são feitas em conjunto, ora não. São elas:
1. Alteração no schema de banco de dados – Mudanças executadas com base em queries DDL (Data Definition Language);
2. Alteração de dados do SGBD – Mudanças executadas com base em queries DML (Data Manipulation Language);
3. Alteração de acessos do banco de dados – Mudanças executadas com base em queries DCL (Data Control Language).
Muitas refatorações de banco de dados, tais como adicionar uma coluna, podem ser feitas sem ser preciso atualizar áreas do código da aplicação. Por outro lado, existem mudanças que são caracterizadas como alterações destrutivas. Essas refatorações são conhecidas dessa forma porque sua implementação pode fazer com que surjam erros no sistema. Como exemplo teríamos tornar uma coluna NULL como NOT NULL.
Alterações destrutivas precisam de um pouco mais de cuidado e o grau de atenção irá depender do quanto a mudança é prejudicial ao ambiente. O importante é escolher em conjunto com o time um procedimento apropriado para cada tipo de mudança. Se houver um controle adequado do sistema, mesmo que ocorra algum problema, não será difícil revertê-lo e corrigi-lo.
Uma boa prática para o conceito de banco de dados evolutivo é sempre atualizar automaticamente todas as sandbox quando o banco de dados master for alterado. O mesmo script que atualiza a base de dados central atualizará todas as instâncias de banco de dados dos desenvolvedores.
Dessa maneira, há uma impossibilidade de um desenvolvedor executar um commit em uma alteração e modificar a base master que já havia sido atualizada por outro programador.
Para implementar e trabalhar com todo esse conceito seria necessária uma grande quantidade de tarefas repetitivas. Porém, existem ferramentas que auxiliam e automatizam grande parte do trabalho de versionamento de banco de dados.
LiquiBase
Existem várias ferramentas que ajudam na tarefa de refatoração de banco de dados, entretanto, veremos a partir de agora como implementar esse conceito de banco de dados evolutivo usando o LiquiBase.
O LiquiBase é uma ferramenta de versionamento open source em Java criada para gerenciar as mudanças de banco de dados.
Em vez do desenvolvedor escrever o SQL diretamente no banco de dados
para criar, atualizar ou descartar objetos, essas definições são escritas em
arquivos XML. Esse arquivo XML é denominado changelog que, por sua vez, contém
vários changesets que nada mais são que cada uma das alterações de banco. Nas Listagens 1 e 2 temos um exemplo da estrutura do changelog e changeset.
Listagem 1. Estrutura do arquivo de ChangeLog da ferramenta de versionamento de banco de dados LiquiBase
01 <databaseChangeLog
02 xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
03 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
04 xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext"
05 xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
06 http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd
07 http://www.liquibase.org/xml/ns/dbchangelog-ext
08 http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd">
09
10 </databaseChangeLog>Listagem 2. Estrutura do arquivo de ChangeSet da ferramenta de versionamento de banco de dados LiquiBase
01 <changeSet author="arthur" id="apresentacao_liquibase">
02
03 <createTable tableName="sql_magazine">
04 <column name="id" type="int"/>
05 <column name="nome" type="varchar(255)"/>
06 </createTable>
07
08 </changeSet>O LiquiBase cria no banco de dados a ser versionado duas tabelas de controle: databasechangelog e databasechangeloglock. Essas tabelas serão geradas no primeiro comando que você executar através do LiquiBase. Na tabela databasechangelog, o LiquiBase guarda as informações de changesets aplicadas na base de dados sendo que o XML de alteração é identificado por uma chave composta que contém os campos id e autor. Já a tabela databasechangeloglock serve para não permitir que dois usuários apliquem alterações simultâneas na mesma base de dados.
As mudanças são feitas em arquivos XML que são executados através de comandos via DOS (Windows) ou Terminal (Linux). Os principais comandos são:
· Update – Usado para os comandos de criação, alteração ou descarte de objetos;
· Rollback – Usado para desfazer uma alteração executada na base de dados;
...
