No decorrer do desenvolvimento de um projeto, mudanças podem ocorrer no planejamento, no código e no banco. Mudanças no código são simples de se contornar, pois possuímos ferramentas para controle de versão do código, possibilitando voltar atrás, juntar versões e controlar a vida do nosso código. Porém, o controle de versões do banco de dados relacional (SGBDR) é um pouco mais complexo.

Em algumas empresas, já vi o controle de versões ficar em procedures, em que a cada versão era criada uma proc nova, que iria alterar ou recriar a base e alimentar com dados para teste. Porém eram procs criadas manualmente.

Alguns frameworks de ORM vinham com um controle de versão da base de dados, como exemplo o Hibernate no java, o Active Record no ruby, o Doctrine no php, o projeto open source Migrations.net baseado no Active Record e vários outros. Mas o Entity Framework, framework ORM da Microsoft, open source, não possuía um controle de versão desde o seu início.

O suporte a migrations veio somente na versão 4.3.1 do Entity Framewrok, anteriormente tínhamos apenas três escolhas de estratégias para a criação de data bases: CreateDatabaseIfNotExists, que somente cria a base se ela não existir; DropCreateDatabaseAlways, que sempre apaga e recria o base de dados; DropCreateDatabaseIfModelChanges, que apaga e recria a base somente se o modelo foi alterado – sendo essa a opção mais próxima do que precisávamos, mas ainda não era perfeita, pois acabávamos perdendo os dados antigos e caso precisássemos voltar a versão, não era possível.

Com o Code First Migrations, podemos ter versões da base de dados, voltar versões e manter um histórico. O Migrations vigia suas classes POCO e cria métodos de update e downgrade com o código necessário para aplicar as mudanças. Algo interessante é ressaltar que podemos alterar com lambda expressions ou com SQL puro as mudanças que o Migrations vai fazer.

Mas para utilizar o Migrations, você precisa habilitá-lo. Para isso, na Package Manager Console use o comando:

Enable-Migrations

Mesmo que você não tenha habilitado na criação da sua base de dados, se criada pelo Code First, vai ser criada uma tabela do sistema com a migration inicial. Ao habilitar a migrations, vai ser criada uma pasta para os arquivos de código das migrations. Depois você tem dois caminhos: migrations normal e automatic migrations.

Migrations normal

O caminho normal da migrations consiste em, por linha de comando, você criar uma migration dando um nome para ela e depois rodando o comando de update. Sem fizer isso, vai ser gerada uma exception a cada vez que seu modelo mudar. Um exemplo é:

Add-Migration NomeDaMigration
Update-database

Ao adicionar uma migration, vai ser adicionado um arquivo com o código da migration na pasta Migrations do seu projeto (o nome é um timestamp seguido do nome que você deu a sua migration), como mostra a próxima imagem. É por esse timestamp que a migrations sabe a ordem delas.

Nesse arquivo, você vai encontrar uma partial class com os métodos de Up e Down. O Up será rodado no update da base de dados para aquela migration e o Down, quando você estiver numa versão posterior e quiser voltar até ela. Você pode sobre escrever esses métodos e mudar a sua lógica de Up e Down.

.

Como você pode ver, é usado por default lambda expressions, mas você pode incluir código SQL se quiser. Você também pode ver o código SQL gerado usando o parâmetro -Verbose na hora de rodar o update. E para não rodar o update, e só ver o Sql que seria gerado (caso queira rodá-lo manualmente), use o parametro -script.

Caso esteja numa versão posterior e queira voltar uma versão, é só, ao rodar o comando update, dizer o nome completo da migration com o parâmetro TargetMigration, incluindo o timestamp, como no exemplo:

Update-Database -TargetMigration:"201210301049442_second2"

Automatic migrations

Ao usar o caminho automatic migrations você não precisa criar uma migration a cada mudança no modelo, somente rodar o comando update. Apesar de parecer mais rápido, tem os contras: não possui um scaffolding para a geração de métodos de update e downgrade, afinal, você não cria pontos intermediários de versão.

Para habilitar o automatic migrations você tem dois caminhos: rodando um comando na Package Manager Console:

Enable-Migrations -EnableAutomaticMigrations

Ou habilitando via código na Configuration geral das suas migrations (classe que é criada dentro da pasta Migrations):

Migration:AutomaticMigrationsEnabled = true;

Bem, esse é o modo de usar Entity Framework Migrations. O Entity Framework 6 já está em alpha, em breve poderemos ter mais novidades na Migrations.

Até lá!

Publicado originalmente na Technet Wiki: