Em projetos ágeis em que todos os desenvolvedores estão habituados à metodologia, a evolução e a refatoração do código são realizadas com prazer, motivação, produtividade e qualidade. Além disso, essa evolução pode ser acompanhada por boas ferramentas de testes, de refatoração, de coleta de métrica e de planejamento e gerenciamento do projeto.
Entretanto, quando o objeto em questão é o banco de dados, o processo nem sempre anda da mesma forma como ocorre com o código.
Primeiro porque se costuma verificar conflitos entre os programadores e os DBAs, pois geralmente estes trabalham seguindo processos nem sempre flexíveis, afinal estão trabalhando com todo cuidado para que os dados possam ser mantidos por longo tempo.
E segundo porque as ferramentas já mencionadas não são tão eficazes, ou simplesmente não existem, quando voltadas à evolução e refatoração do banco de dados, pois alterar/refatorar banco de dados é muito mais difícil do que acrescentar/refatorar código.
Antes de realizar qualquer refatoração no banco de dados, é preciso estar ciente de que ela precisa preservar tanto a semântica comportamental das aplicações que acessam a base, como também a semântica informacional, ou seja, preservar o significado que das informações no banco de dados do ponto de vista dos usuários destas informações. Assim, qualquer alteração na base, seja ela uma refatoração, transformação ou migração, precisa ser submetida frequentemente a testes de integração, e posteriormente controlada em um ambiente de homologação antes que essas alterações sejam aplicadas na base de produção. Dessa forma, pode-se realizar a modelagem de dados de forma ágil e precisa, além de controlar a evolução das instâncias do banco de dados.
Para que a evolução do banco de dados ocorra de forma suave seguindo estes passos, é preciso adotar algumas medidas estratégicas e de melhores práticas. Começando do ambiente de desenvolvimento, faz-se necessário a utilização de controlador de versão que deve conter o arquivo com os scripts identificados unicamente pela alteração proposta, além de um banco de dados individual.
Ainda na etapa de desenvolvimento, é importante adotar um ciclo de vida de uma alteração da base de dados (ver figura acima), que envolve a aplicação dos scripts afins obtendo uma estrutura/tabela nova, e antes que a estrutura/tabela antiga seja considerada obsoleta, é preciso verificar se a alteração realmente é apropriada. Essa verificação é um processo que envolve:
- a criação de exaustivos testes automatizados para a base de dados
- modificação da(s) estrutura(s) através dos scripts
- migração dos dados quando necessária (em uma refatoração completa por exemplo)
- refatoração dos aplicativos
- execução dos testes
Uma vez que todos os testes foram validados em desenvolvimento, os scripts são enviados ao controlador de versão, e finalmente a alteração é anunciada. Assim, essa alteração é submetida aos testes do ambiente de integração contínua e posteriormente ao ambiente de homologação.
Após todas essas etapas terem sido validadas, a alteração pode ser submetida ao ambiente de produção e após aplicar a alteração, executar os testes para mais uma vez validar as alterações. É estritamente recomendado realizar um backup da base, antes de submeter a alteração ao ambiente de produção.
Todos os processos acima podem se tornar mais ágeis quando se adota algumas boas práticas, como:
Alterações pequenas podem ser agrupadas formando uma única alteração grande
Identificar unicamente cada alteração
Simplificar tanto o processo de negociação de alterações com outros times de desenvolvimento, como o processo de controle de alteração do banco de dados
Não duplicar scripts SQL, dispondo-os em um único lugar
Utilização de algum software de integração contínua para a execução dos scripts
Quanto à refatoração em base de dados, recomenda-se como referência dois livros que enumeram diversos tipos de refatoração e como realizá-las de forma adequada:
- Refactoring Databases (Scott W. Ambler e Pramod J. Sadalage – 2006)
- Recipes for Continuous Database Integration (Pramod J. Sadalage – 2007)
Seguindo todos os passos e implementando gradualmente as melhores práticas é possível evoluir gradualmente o banco de dados em projetos ágeis, e de maneira equilibrada com outros times de desenvolvimento e DBAs. Entretanto, ainda percebe-se uma lacuna nas ferramentas que auxiliem ou que automatizem esse processo quando se adota metodologias ágeis diante as evoluções mais complexas.
Referências: Refactoring Databases (Scott W. Ambler e Pramod J. Sadalage – 2006) http://www.agiledata.org
