Comparação e seleção de sistemas de migração de dados
O modelo de dados tende a mudar durante o processo de desenvolvimento, e em algum momento não corresponde mais ao banco de dados. Claro, o banco de dados pode ser excluído e então o ORM criará uma nova versão que corresponda ao modelo, mas este procedimento levará à perda dos dados existentes. Assim, a função do sistema de migração é garantir que, em decorrência de uma mudança de esquema, ele seja sincronizado com o modelo de dados da aplicação sem perder os dados existentes.
Neste artigo, gostaríamos de examinar várias ferramentas para gerenciar migrações de banco de dados. Esperamos que esta análise seja útil para desenvolvedores que enfrentam uma escolha semelhante.
Tarefa
Nossa empresa está atualmente desenvolvendo ativamente a próxima geração de produtos – Docs Security Suite (DSS). A parte do servidor é escrita em .Net Core e o Entity Framework Core é usado como DBMS. Ao projetar um aplicativo, usamos a abordagem Code First.
O modelo de domínio do aplicativo é criado por vários desenvolvedores ao mesmo tempo - cada um é responsável por sua própria parte lógica do sistema.
A geração anterior do DSS usava o clássico Entity Framework Migrations (EF 6) como sistema de gerenciamento de migração. No entanto, algumas reclamações se acumularam contra ele, sendo a principal delas que a EF carece de uma abordagem sensata para resolver conflitos de versão. Este fato ainda nos incomoda na hora de corrigir bugs como parte do suporte, então decidimos considerar opções alternativas.
Como resultado da discussão, foram formados os seguintes requisitos para o sistema de gestão de migração:
- Suporte para vários SGBDs. MS SQL Server, PostgreSQL, Oracle são necessários, mas é potencialmente possível usar outros
- Trabalhando com ORM. Inicialmente, foi planejado o uso do EF Core, mas na fase de design estávamos prontos para considerar outros ORMs
- Geração automática de migrações. Levando em consideração o desenvolvimento do Code First, gostaria de evitar a necessidade de “escrever à mão” as migrações
- Conflitos de versão. Em um ambiente de desenvolvimento distribuído, durante a fusão, o EF Core pode sofrer conflitos. Isso se torna um problema significativo porque diferentes partes do aplicativo são criadas por desenvolvedores diferentes, então você precisa gastar muito tempo em cada uma delas.
- Documentação e suporte avançados. Aqui, parece-nos, nenhuma explicação é necessária
- Livre. O critério é condicional, já que os sistemas não são muito caros nem caros, mas ideais em conveniência, também estávamos prontos para considerar
Como resultado de um pouco de pesquisa, as seguintes opções foram encontradas e consideradas desejáveis para consideração:
- Migrações do EF Core
- DBup
- Roundhouse E
- PensandoCasa.Migrador
- Migrador Fluente
E agora um pouco mais de detalhes
Naturalmente, esta foi a primeira e principal opção a escolher. Um instrumento nativo que funciona imediatamente, sem mexer no pandeiro. Grande quantidade de documentação, oficial e nem tanto, simplicidade, etc. No entanto, as reclamações feitas sobre o EF clássico também são bastante relevantes para o EF Core.
Assim, destacam-se as vantagens do EF Core:
- Suporte da Microsoft, documentação, inclusive em russo, enorme comunidade
- Geração automática de migrações com base no CodeFirst
- Comparado ao EF 6, o EF Core não armazena mais um instantâneo do banco de dados. Ao trabalhar com o EF Core no Code First, não é mais necessário implantar um banco de dados
- Como estamos dançando a partir do Code First, é possível realizar uma migração para todos os provedores de acesso a dados necessários
- Em relação aos provedores, há suporte para PostgreSQL, suporte para Oracle, etc., etc., e até mesmo MS SQL Server
E também as desvantagens:
- A resolução de conflitos permaneceu no mesmo nível. É necessário sequenciar migrações e atualizar snapshots de banco de dados
- Dependência dos modelos sobre os quais as migrações são geradas
DbUp
DbUp é uma biblioteca .NET instalada pelo NuGet e ajuda a enviar alterações para o SQL Server. Ele monitora quais scripts de mudança já foram executados e executa aqueles que são necessários para atualizar o banco de dados. A biblioteca surgiu de um projeto para um mecanismo de blog de código aberto no ASP.NET e existe sob uma licença do MIT, e o código está no GitHub. As migrações são descritas usando T-SQL.
Quais são as vantagens:
- Suporte para um grande número de DBMS (MS SQL Server, PstgreSQL, MySQL)
- Como os scripts são escritos em T-SQL, eles parecem bastante simples
- Os conflitos também são resolvidos usando SQL
E os contras:
- Com toda a variedade de SGBDs suportados, a Oracle não é um deles
- Não interage com ORM
- Escrever scripts T-SQL manualmente não é o que pretendíamos
- A documentação e a comunidade são razoáveis, embora em termos de escrita de scripts SQL elas possam não ser necessárias.
Roundhouse E
Esta ferramenta de gerenciamento de migração, distribuída sob a licença Apache 2.0, como a anterior, roda no mecanismo de migração T-SQL. Aparentemente, os desenvolvedores priorizaram a resolução de problemas técnicos relacionados ao suporte do SGBD, ao invés de criar um processo de desenvolvimento confortável.
Prós:
- Suporta o SGBD necessário (incluindo Oracle)
Contras:
- Oracle (assim como Access, que é irrelevante para nós) não é suportado no .NET Core, apenas no .NET Full Framework
- Não funciona com ORM
- Há ainda menos documentação do que a ferramenta anterior
- Novamente – as migrações são escritas por scripts
PensandoCasa.Migrador
Uma ferramenta para migração de esquema de banco de dados versionado para a plataforma .NET Core, distribuída sob licença MIT. .
Prós:
- Projetado para .NET Core
- Implementou uma sequência ramificada de migrações
- Registro de migração implementado
Contras:
- Última atualização há um ano. Aparentemente o projeto não é suportado
- Não suportado pela Oracle (o artigo afirma que isso se deve à falta de uma implementação estável para o .NET Core - mas isso foi há um ano)
- Sem geração automática de migrações
No geral, o projeto parece promissor, especialmente se for desenvolvido, mas precisávamos tomar uma decisão aqui e agora.
Migrador Fluente
A ferramenta de migração mais popular com um grande exército de fãs. Distribuído sob a licença Apache 2.0. Conforme declarado na descrição, é uma estrutura de migração para .NET, semelhante às migrações Ruby on Rails. As alterações no esquema do banco de dados são descritas em classes C#.
Existem vantagens aqui:
- Suporte para DBMS necessário
- Suporte ao .NET Core
- Grande comunidade desenvolvida
- Os conflitos entre migrações são resolvidos sequencialmente – a ordem de execução das migrações é especificada. Além disso, se surgir um conflito em torno de uma entidade, ao mesclar o código, ele será resolvido da mesma forma que no resto do código
- Existem perfis que são executados após uma migração bem-sucedida. E podem realizar funções de serviço. A última atualização foi há um mês, ou seja, o projeto está vivo
Quanto aos pontos negativos, aqui estão eles:
- Sem geração automática de migrações
- Sem conexão com modelos EF
- Nenhum instantâneo do banco de dados
Qual foi a nossa escolha?
Os debates acalorados giraram em torno de dois parâmetros - geração automática de migrações e resolução sensata de conflitos. Outros fatores foram muito menos assustadores. Como resultado, com base nos resultados da discussão, a equipe decidiu usar o Fluent Migrator no novo projeto. Porque a resolução de conflitos no futuro trará muito mais benefícios.
Descobertas
É claro que não existem ferramentas perfeitas. Então tivemos que priorizar nossos “desejos” para fazer uma escolha. Contudo, para outras equipas e outras tarefas, outros fatores podem ser decisivos. Esperamos que este artigo o ajude a fazer uma escolha.
Fonte: habr.com