O código das aplicações está no Git há anos. Em muitas equipas, a base de dados ainda não está. O esquema vive em produção, as alterações são escritas como scripts no portátil de alguém, e o único registo completo do que mudou é a própria base de dados.
Isso dificulta qualquer outra melhoria. Não consegue rever uma alteração que não vê, não consegue testar uma implementação que não consegue repetir, e não consegue automatizar uma release quando ninguém sabe ao certo em que estado está a base de dados de destino.
Em artigos anteriores vimos o que é o Redgate Flyway e porque é que os atrasos nas bases de dados reduzem o retorno da automatização. Este artigo trata do primeiro passo prático: colocar uma base de dados existente sob controlo de versões.
O que o controlo de versões lhe dá
Assim que a base de dados está no Git, cada alteração tem um autor, uma data e uma razão. As alterações passam pelos mesmos pull requests que o código da aplicação, para que um especialista em bases de dados as possa rever antes de chegarem a produção, e não depois. E como os scripts estão no repositório, cada ambiente pode ser construído a partir da mesma fonte.
Também muda a conversa sobre releases. A pergunta já não é quem executou o quê, e onde. É em que versão está uma base de dados.
Comece pelo que está a funcionar hoje
A maioria das equipas não começa com uma base de dados vazia. A primeira tarefa é registar o estado atual como ponto de partida.
Com o Flyway há dois caminhos habituais. Pode gerar o script do esquema existente como primeira migração, para que um ambiente novo possa ser construído de raiz. Ou pode usar o flyway baseline para indicar ao Flyway que uma base de dados existente já está numa determinada versão, para que só sejam aplicadas as alterações posteriores. A maioria das equipas precisa das duas coisas: um script que constrói uma base de dados limpa para desenvolvimento e testes, e uma baseline para as bases de dados de produção que já existem.
Antes de registar o que quer que seja, compare os seus ambientes. Desenvolvimento, testes e produção raramente coincidem por completo. Um índice adicionado durante um incidente ou um procedimento corrigido diretamente em produção resolve-se mais facilmente agora do que depois de ter causado uma implementação falhada.
A partir daí, versione cada alteração
A partir da baseline, cada alteração é um script de migração no repositório. O Flyway aplica as versioned migrations por ordem e regista cada uma numa tabela de histórico do esquema dentro da base de dados, para saber sempre que scripts uma base de dados já recebeu.
Alguns acordos tornam isto viável na prática:
- Uma alteração por migração, com um nome que diz o que faz.
- Uma migração que já foi executada nunca é editada. Uma correção é uma nova migração.
- Views, stored procedures e funções podem ser mantidas como repeatable migrations, que o Flyway volta a aplicar sempre que o conteúdo muda.
- Os dados de referência de que a aplicação depende também pertencem ao controlo de versões. Os dados dos clientes não.
Deixe o pipeline fazer as implementações
Com a base de dados no Git, o pipeline pode assumir o trabalho que antes se fazia à mão. Um pull request executa as migrações numa base de dados de testes, para que um script com erros falhe no build e não numa janela de manutenção. Depois da aprovação, os mesmos scripts passam pela mesma ordem por testes, aceitação e produção.
O Flyway corre a partir da linha de comandos, por isso encaixa no Azure DevOps, no GitHub Actions ou em qualquer outro sistema de CI. As equipas no GitHub podem usar as Flyway Actions da Redgate.
Consoante a edição e a plataforma de base de dados, o Flyway acrescenta verificações que ajudam quem revê: relatórios do que uma implementação vai alterar, verificações automáticas do código e deteção de drift, que trava uma release quando a produção foi alterada fora do processo.
Preocupações frequentes
A nossa base de dados é demasiado grande ou demasiado antiga. O tamanho conta para os dados, não para o esquema. Uma baseline regista a estrutura, e o Flyway só aplica as alterações que vêm depois.
Os nossos DBAs vão perder o controlo. Ganham-no. Reveem cada alteração no pull request, e a produção só recebe o que foi aprovado. O acesso à produção pode continuar limitado ao pipeline.
Fazemos correções urgentes diretamente em produção. Às vezes é necessário. Combine que cada correção urgente é acrescentada ao repositório depois, e use a deteção de drift para encontrar as que não foram.
Por onde começar
Escolha uma aplicação cuja base de dados muda com frequência e causa atrito. Compare os seus ambientes, registe uma baseline e faça passar a próxima alteração por um pull request e um pipeline. Uma alteração de rotina que chega a produção sem nenhum passo manual é um argumento melhor do que qualquer apresentação.
A Masterminds é Redgate Gold Partner há muitos anos. As nossas equipas de DevOps e de dados ajudam na primeira avaliação, na baseline e no pipeline, veja Database Automation com Redgate Flyway. Fale connosco se quiser colocar a sua primeira base de dados sob controlo de versões.
