Levando o Controle de Alterações na Base de Dados para o Código

Um dos maiores problemas em um projeto de software é o controle de publicação de novas versões. Esse trabalho envolve um longo processo de revisão de código, atualização dos ambientes no qual faremos a publicação, (que pode incluir novos plugins) e um dos maiores problemas: as alterações feitas no modelo de dados da aplicação.

Caso você não esteja usando um framework de persistência que se encarregue de manter o equilíbrio entre o modelo de domínio e a base de dados, você vai precisar adotar algum processo exclusivo para manter o controle das alterações. Como por exemplo:



Hoje em dia é comum vermos equipes pequenas desenvolvendo aplicações orientadas a dados sem a presença de um recurso específico para manter o controle da base e das alterações (o DBA). Geralmente as alterações são documentadas em algum tipo de repositório na rede, ou até mesmo compartilhada por email entre os desenvolvedores (Caso estejam comitando o código e trabalhando com bases locais).

Acontece que a maioria dos processos estabelecidos são sujeitos a falhas e o controle pode se perder, principalmente quando um sistema muito antigo precisa ser atualizado para a última versão (do 1.0 pro 3.4, por exemplo). Pensando nesse problema resolvi passar o controle de documentação e execução das alterações de um determinado projeto para o código, me baseando no EntityFramework Migrations.

O conceito que eu tirei do Migrations é muito simples: Cada alteração feita na base de dados, gera uma nova migration. Essa migration recebe um número sequencial de versão e contém dois scripts diferentes:
               Up: Script para publicação da alteração. (Por exemplo, criar uma tabela nova)
               Down: Script para desfazer uma alteração. (Por exemplo, um drop de coluna. O script 'Down' é muito importante caso alguma publicação de release precise ser revertida. Ele funciona como um Recovery Plan da alteração)


Abaixo segue o diagrama do processo baseado em código:

Abaixo segue a implementação do código.

Primeiro, as classes que servem de base para as alterações adicionadas.

Sempre que um desenvolvedor da "commit" em uma alteração do banco, ele deve ao invés de encaminhar para o DBA, criar uma nova classe no projeto, com base nesta classe abaixo:

 * o maior problema da implementação é que o número da alteração é gerado em hardcode. O desenvolvedor precisa estar atento para não haver duplicidade, mas isso pode ser facilmente resolvido com um pouco mais de capricho.

O namespace também disponibiliza um controlador para acionar a verificação automática de versão da base:

Agora na aplicação web, adicionamos ao arquivo Global.asax a chamada ao controlador, passando as dependências necessárias, a aplicação checa por um número de versão no web.config da aplicação, caso não encontre ele atualiza a base para a última versão com base nas classes adicionadas ao framework DataBaseMigrations.Versoes :