0

Dia a dia das Migrations

#Ruby #Laravel #Banco de dados relacional
Francisco Barroso
Francisco Barroso

Neste artigo vou falar um pouco sobre Migrations, mesmo sendo um assunto simples muitas vezes existem momentos do dia a dia em que o desenvolvedor pode se complicar com o uso das Migrations.


Antes vamos relembrar como era feito o gerenciamento do esquema de banco de dados. Durante um tempo os devs precisavam gerenciar a evolução do banco da aplicação por conta própria e lembro um pouco do trabalho que envolvia este assunto.


Os problemas acontecem proporcionalmente a quantidade de devs na equipe, imagina você em uma equipe com 10 pessoas e todos alterando um único arquivo que representava a estrutura do banco. Era comum um dev commitar "alter table" duplicado, remover campos que estavam sendo usados por outro dev ou até mesmo perder parte do esquema. Claro que o Git ajudou muito neste ponto, não podemos negar. Mas os problemas ainda existiam antes das Migrations.


Antigamente era comum o banco de um dev não funcionar direito, pois estava com o esquema corrompido e acabava quebrando os testes ou até mesmo impossibilitava que o ambiente local funcionasse. Sem falar em problemas com os servidores de build, mas este é um assunto para um próximo post.


Migrations é uma forma de diminuir este problema, o esquema não é mais representado por um único arquivo e sim um conjunto de pequenos arquivos, cada arquivo é nomeado com um timestamp que facilita a execução correta do script. Hoje vários frameworks implementaram esse modelo, mas ele foi popularizado com o Ruby on Rails e realmente diminuiu muito os problemas com banco de dados.


As Migrations tem um Up e um Down, ou seja elas devem saber fazer um determinada ação e desfazer. Em caso de rollback o Down deve devolver o estado anterior do esquema. Fique de olho, pois às vezes os desenvolvedores não ligam muito para o Down, pois acham que não vão precisar dar rollback no banco.


Imagine a seguinte situação: Você está trabalhando em um branch junto com seu colega e você já rodou duas Migrations, deu tudo certo e o trabalho continua. Mas você precisou mudar para um outro branch que ainda não recebeu as alterações que vocês fizeram no branch anterior, neste momento seu banco está diferente e provavelmente os testes não vão passar. Então você precisa rodar o rollback das duas Migrations ainda no branch anterior. Este é um ponto que ainda atrapalha o dia a dia dos devs, se ligou?


Uma última dica, nunca edite uma Migrations que já foi "commitada", enviada para os outros devs. Pois você vai ficar com um esquema diferente dos seus colegas, por que caso alguém já tenha rodado aquela Migrations ela não será executada de forma automática novamente. O outro dev vai precisar fazer uma intervenção por meio do rollback.


Então é isso pessoal, Migrations realmente ajuda muito os desenvolvedores. Precisamos tomar alguns cuidados e manter nosso ambiente organizado. Abraços e até o próximo post!!!

0
6

Comentários (1)

0
Rodrigo Valente

Rodrigo Valente

31/03/2021 08:53

Meus primeiros contatos com Migrations estão sendo há alguns dias e realmente é fantástico, pois gera um padrão de trabalho bacana e ainda minimiza as possibilidades de erro em equipes!

Engineering Manager

Brasil