A migração de esquema permite corrigir erros e adaptar os dados como os requisitos mudam. Eles são uma parte essencial da evolução do software, especialmente em ambientes ágeis (veja abaixo).
A aplicação de uma migração de esquema a um banco de dados de produção é sempre um risco. Os bancos de dados de desenvolvimento e teste tendem a ser menores e mais limpos. Os dados neles são melhor compreendidos ou, se todo o resto falhar, a quantidade de dados é pequena o suficiente para um humano processar. Os bancos de dados de produção geralmente são enormes, antigos e cheios de surpresas. As surpresas podem vir de muitas fontes:
Corrupt data that was written by old versions of the software and not cleaned properlyImplied dependencies in the data which no one knows about anymorePeople directly changing the database without using the designated toolsBugs in the schema migration toolsMistakes in assumptions how data should be migratedPor esses motivos, o processo de migração precisa de um alto nível de disciplina, testes completos e uma estratégia de backup de som.
As migrações de esquema podem levar muito tempo para concluir e, para sistemas que operam 24 horas por dia, 7 dias por semana, é importante poder fazer migrações de banco de dados sem tempo de inatividade. Geralmente é feito com a ajuda de sinalizadores de recursos e entrega contínua.
Ao desenvolver aplicativos de software apoiados por um banco de dados, os desenvolvedores normalmente desenvolvem o código -fonte do aplicativo em conjunto com um esquema de banco de dados em evolução. O código normalmente possui expectativas rígidas de quais colunas, tabelas e restrições estão presentes no esquema de banco de dados sempre que precisar interagir com um, portanto, apenas a versão do esquema de banco de dados em que o código foi desenvolvido é considerado totalmente compatível com essa versão do código -fonte .
Nos testes de software, embora os desenvolvedores possam zombar da presença de um sistema de banco de dados compatível para testes de unidade, qualquer nível de teste mais alto que esse (por exemplo, teste de integração ou teste do sistema) é comum que os desenvolvedores testem sua aplicação em um banco de dados de teste local ou remoto esquematicamente compatível com a versão do código -fonte em teste. Em aplicações avançadas, a própria migração pode estar sujeita a testes de migração.
Com a tecnologia de migração de esquema, os modelos de dados não precisam mais ser totalmente projetados para frente e são mais capazes de serem adaptados com a mudança dos requisitos do projeto ao longo do ciclo de vida do desenvolvimento de software.
As equipes de desenvolvedores de software geralmente usam sistemas de controle de versão para gerenciar e colaborar nas alterações feitas nas versões do código -fonte. Desenvolvedores diferentes podem se desenvolver em ramificações divergentes, relativamente mais antigas ou mais recentes do mesmo código -fonte para fazer alterações e adições durante o desenvolvimento.
Supondo que o software em desenvolvimento interage com um banco de dados, todas as versões do código -fonte podem ser associadas a pelo menos um esquema de banco de dados com o qual é compatível.
Em boas práticas de teste de software, as migrações de esquema podem ser realizadas nos bancos de dados de teste para garantir que seu esquema seja compatível com o código -fonte. Para otimizar esse processo, uma ferramenta de migração de esquema geralmente é invocada como parte de uma construção de software automatizada como um pré -requisito da fase de teste automatizada.
Pode -se dizer que as ferramentas de migração de esquema resolvem problemas de versão para esquemas de banco de dados, assim como os sistemas de controle de versão resolvem problemas de versão para o código -fonte. Na prática, muitas ferramentas de migração de esquema realmente dependem de uma representação textual de alterações de esquema (como arquivos que contêm instruções SQL), de modo que o histórico da versão das alterações do esquema possa ser efetivamente armazenado juntamente com o código -fonte do programa no VCS. Essa abordagem garante que as informações necessárias para recuperar um esquema de banco de dados compatíveis para uma ramificação de código específico seja recuperável da própria árvore de origem. Outro benefício dessa abordagem é o manuseio de mudanças de esquema conflitante simultâneas; Os desenvolvedores podem simplesmente usar suas ferramentas usuais de resolução de conflitos baseadas em texto para conciliar diferenças.
As ferramentas de migração de esquema podem ser vistas como uma instalação para rastrear a história de um esquema em evolução.
Os desenvolvedores não precisam mais remover todo o banco de dados de teste para criar um novo banco de dados de teste do zero (por exemplo, usando scripts de criação de esquema das ferramentas de geração DDL). Além disso, se a geração de dados de teste custar muito tempo, os desenvolvedores podem evitar a regeneração de dados de teste para pequenas alterações não destrutivas no esquema.