Comparação e escolha de sistemas de migração de dados
O modelo de dados durante o processo de desenvolvimento tem a propriedade de mudar, e em algum momento ele deixa de corresponder ao banco de dados. Claro, o banco de dados pode ser excluído, e então o ORM criará uma nova versão que corresponderá ao modelo, mas esse procedimento resultará na perda de dados existentes. Assim, a função do sistema de migração é sincronizar a estrutura com o modelo de dados no aplicativo sem perda de dados existentes.
Neste artigo, gostaríamos de discutir várias ferramentas para gerenciar migrações de bancos de dados. Esperamos que esta visão geral seja útil para desenvolvedores enfrentando uma escolha semelhante.
Tarefa
Nossa empresa atualmente está desenvolvendo ativamente a próxima geração do produto – Docs Security Suite (DSS). A parte do servidor está sendo escrita em .Net Core, e, como SGBD, está sendo utilizado o Entity Framework Core. Ao projetar o aplicativo, utilizamos a abordagem Code First.
O modelo de domínio do aplicativo é criado simultaneamente por vários desenvolvedores – cada um responsável por sua parte lógica do sistema.
Na geração anterior do DSS, foi utilizado o clássico Entity Framework Migrations (EF 6) como sistema de gestão de migrações. No entanto, surgiram algumas reclamações, sendo a principal que o EF carecia de uma abordagem razoável para resolução de conflitos de versões. Esse fato ainda nos desagrada durante a correção de bugs no suporte, por isso decidimos considerar alternativas.
Como resultado das discussões, foram formados os seguintes requisitos para o sistema de gestão de migrações:
- Suporte a diferentes SGBDs. É obrigatório o MS SQL Server, PostgreSQL, Oracle, mas o uso de outros também é potencialmente possível.
- Trabalho com ORM. Inicialmente, estava previsto o uso do EF Core, mas durante a fase de projeto estávamos dispostos a considerar outras ORMs.
- Geração automática de migrações. Considerando o desenvolvimento Code First, gostaríamos de evitar a necessidade de "escrever manualmente" as migrações.
- Conflitos de versões. Em condições de desenvolvimento distribuído, ao mesclar, o EF Core pode falhar devido a conflitos. Isso se torna um problema significativo, uma vez que diferentes partes do aplicativo são criadas por diferentes desenvolvedores, resultando em uma grande quantidade de tempo gasto em cada um.
- Documentação e suporte avançados. Aqui, acreditamos que explicações não são necessárias.
- Gratuidade. O critério é condicional, pois sistemas que não são muito caros ou aqueles que são caros, mas ideais em termos de conforto, também estamos prontos para considerar.
Como resultado de uma pequena pesquisa, foram encontrados e reconhecidos como desejáveis para consideração as seguintes opções:
- Migrations do EF Core
- DBup
- RoundhousE
- ThinkingHome.Migrator
- Fluent Migrator
Agora, um pouco mais detalhado
Naturalmente, esta foi a primeira e principal opção a ser escolhida. Uma ferramenta nativa que funciona out of the box, sem quaisquer complicações. Uma grande quantidade de documentação, oficial e não oficial, simplicidade, etc. No entanto, as críticas feitas ao clássico EF são totalmente pertinentes ao EF Core.
Assim, os prós do EF Core são:
- Suporte da Microsoft, documentação, incluindo em português, uma enorme comunidade.
- Autogeração de migrations com base no CodeFirst.
- Em comparação com o EF 6, no EF Core agora não há mais o armazenamento de um snapshot do banco de dados. Ao usar o EF Core com Code First, não é mais obrigatório implementar um banco de dados.
- Como estamos partindo do Code First, é possível manter uma migration para todos os provedores de acesso a dados necessários.
- Quanto aos provedores — são suportados PostgreSQL, Oracle, etc., e até mesmo – MS SQL Server :)
E também os contras:
- A resolução de conflitos permanece no mesmo nível. É necessário organizar a sequência de migrations e atualizar os snapshots do banco de dados.
- Dependência dos modelos a partir dos quais as migrations foram geradas.
DbUp
DbUp é uma biblioteca .NET que pode ser instalada via NuGet e ajuda a aplicar mudanças no SQL Server. Ela rastreia quais scripts de mudanças já foram executados e executa aqueles que são necessários para atualizar o banco de dados. A biblioteca surgiu de um projeto de motor de blogs open source em ASP.NET e está sob a licença MIT, com o código disponível no GitHub. As migrations são descritas usando T-SQL.
Quais são os prós aqui:
- Suporte a uma ampla gama de SGBDs (MS SQL Server, PostgreSQL, 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:
- Apesar da vasta gama de SGBDs suportados, o Oracle não está entre eles.
- Não interage com ORM.
- Escrever scripts em T-SQL manualmente não é o que buscamos.
- A documentação e a comunidade são medianas, embora talvez não sejam necessárias no contexto da escrita de scripts SQL.
RoundhousE
Esta ferramenta de gerenciamento de migrações, distribuída sob a licença Apache 2.0, assim como a anterior, opera com o mecanismo de migrações T-SQL. Aparentemente, os desenvolvedores priorizaram a resolução de problemas técnicos relacionados ao suporte a SGBDs, em vez de criar um processo de desenvolvimento confortável.
Acesso direto aos sistemas de cabos transpacíficos. Ping mínimo para a China, Japão, Austrália e costa oeste dos EUA.
- Suporta os SGBDs necessários (incluindo o Oracle)
Pontos negativos:
- Oracle (e também o desatualizado Access) não é suportado no .NET Core, apenas no .NET Full Framework
- Não funciona com ORM
- A documentação é ainda mais escassa do que a da ferramenta anterior
- Novamente, as migrações são escritas em scripts
ThinkingHome.Migrator
Uma ferramenta para migração de versão de esquema de banco de dados para a plataforma .NET Core, distribuída sob a licença MIT. .
Acesso direto aos sistemas de cabos transpacíficos. Ping mínimo para a China, Japão, Austrália e costa oeste dos EUA.
- Voltada para .NET Core
- Foi implementada uma sequência de migrações ramificada
- O registro de migrações foi implementado
Pontos negativos:
- A última atualização foi há um ano. Aparentemente, o projeto não é mantido
- Não suporta Oracle (o artigo indica que isso se deve à falta de uma implementação estável para .NET Core – mas isso foi há um ano)
- Falta a autogeração de migrações
No geral, o projeto parece promissor, especialmente se estivesse em desenvolvimento, mas precisávamos tomar uma decisão aqui e agora.
Fluent Migrator
A ferramenta de migrações mais popular, com uma grande base de fãs. Distribuída sob a licença Apache 2.0. Como indicado na descrição, é uma plataforma de migração para .NET, semelhante ao Ruby on Rails Migrations. As alterações no esquema do banco de dados são descritas em classes em C#.
Aqui estão os pontos positivos:
- Suporte aos SGBDs necessários
- Suporte ao .NET Core
- Uma comunidade grande e desenvolvida
- Os conflitos de migração são resolvidos de maneira sequencial – as migrações especificam a ordem de execução. Além disso, se houver um conflito em torno de uma entidade, durante a mesclagem do código, a resolução é feita da mesma forma que no restante do código
- Existem perfis que são executados após a execução bem-sucedida da migração. E podem conter funções de serviço. A última atualização foi há um mês, ou seja, o projeto está ativo
Quanto aos pontos negativos, aqui estão:
- Falta a autogeração de migrações
- Falta de conexão com modelos EF
- Sem instantâneas do banco de dados
Qual foi, então, nossa escolha?
As discussões mais intensas giraram em torno de dois parâmetros – a autogeração de migrações e a solução viável para conflitos. Outros fatores causaram muito menos preocupação. No final, após a discussão, a equipe decidiu usar o Fluent Migrator no novo projeto. Pois a resolução de conflitos a longo prazo trará muitos mais benefícios.
Como resultado, obtemos um serviço de "monitoramento como serviço", automatizado na linha de produção de integração contínua. O desenvolvedor ou testador precisa apenas definir a lista de métricas em um arquivo JSON, e tudo o mais acontece automaticamente. Obtemos um controle de qualidade transparente dos lançamentos: todas as notificações sobre desempenho, consumo de recursos ou regressões arquitetônicas.
É claro que não existem ferramentas perfeitas. Assim, para nós, foi necessário estabelecer prioridades em nossas "preferências". No entanto, para outras equipes e outras tarefas, diferentes fatores podem ser decisivos. Esperamos que este artigo ajude você a tomar uma decisão.
Fonte: habr.com
