Comparação e seleção de sistemas de migração de dados

Comparação e seleção de sistemas de migração de dados

O modelo de dados no processo de desenvolvimento tem a propriedade de alterar e, em algum momento, deixa de corresponder ao banco de dados. Obviamente, o banco de dados pode ser excluído e o ORM criará uma nova versão que corresponderá ao modelo, mas esse procedimento levará à perda de dados existentes. Portanto, a função do sistema de migração é garantir que, como resultado da alteração do esquema, sincronize-o com o modelo de dados no aplicativo sem perder os dados existentes.

Neste artigo, gostaríamos de considerar várias ferramentas para gerenciar migrações de banco de dados. Esperamos que esta revisão seja útil para desenvolvedores que enfrentam essa opção.

Desafio

Atualmente, nossa empresa está desenvolvendo ativamente a próxima geração do produto - Docs Security Suite (DSS). A parte do servidor é gravada no .Net Core e o Entity Framework Core é usado respectivamente como um DBMS. Ao projetar o 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.

Na geração anterior do DSS, as migrações clássicas do Entity Framework (EF 6) foram usadas como um sistema de gerenciamento de migração. No entanto, algumas reivindicações se acumularam contra ele, a principal delas é que a EF não possui uma abordagem sensata para resolver conflitos de versão. Esse fato ainda nos incomoda ao corrigir bugs no âmbito do suporte, por isso foi decidido considerar opções alternativas.

Como resultado da discussão, os seguintes requisitos para o sistema de gerenciamento de migração foram formados:

1. Suporte para vários DBMSs. MS SQL Server obrigatório, PostgreSQL, Oracle, mas você pode potencialmente usar outros
2. Trabalhe com ORM. Inicialmente, o uso do EF Core era suposto, mas na fase de design, outros ORMs estavam prontos para considerar
3. Geração automática de migrações. Dado o desenvolvimento do Code First, eu gostaria de evitar a necessidade de “pintar com canetas”.
4. Conflitos de versão. Em um ambiente de desenvolvimento distribuído com mesclagem, o EF Core pode travar em conflitos. Isso se torna um problema significativo, porque diferentes partes do aplicativo são criadas por diferentes desenvolvedores; portanto, você precisa gastar muito tempo para cada
5. Documentação e suporte avançados. Aqui, parece-nos, nenhuma explicação é necessária
6. Grátis. O critério condicional, como sistemas não muito caros ou caros, mas ideal em conveniência, também estávamos prontos para considerar

Como resultado de um pequeno estudo, as seguintes opções foram encontradas e consideradas desejáveis ​​para consideração:

1. Migrações de núcleo ef
2. Dbup
3. RoundhousE
4. ThinkingHome.Migrator
5. Migrador fluente

E agora um pouco mais

Migrações principais do EntityFramework

Naturalmente, essa foi a primeira e principal opção de escolha. Uma ferramenta nativa que funciona fora da caixa sem dançar com um pandeiro. Uma grande quantidade de documentação, oficial e não muito, simplicidade, etc. No entanto, as reivindicações apresentadas ao EF clássico são bastante relevantes para o EF Core.

Assim, destacam-se as vantagens do EF Core:

• Suporte, documentação da Microsoft, inclusive em russo, uma enorme comunidade
• Migração automática baseada em CodeFirst
• Comparado ao EF 6, o instantâneo do banco de dados não é mais armazenado no EF Core. Ao trabalhar com o EF Core no Code First, você não precisa mais implantar um banco de dados
• Como estamos dançando do Code First - é possível realizar uma migração para todos os provedores de acesso a dados necessários
• Em relação aos provedores - PostgreSQL, Oracle, etc., etc, etc. e até mesmo - o MS SQL Server é suportado

Bem como contras:

• A resolução de conflitos permaneceu no mesmo nível. É necessário construir uma sequência de migrações e atualizar imagens do banco de dados
• Dependência de modelos com base nos quais as migrações são geradas

Dbup


dbup.imtqy.com

DbUp é uma biblioteca .NET instalada pelo NuGet e ajuda a rolar as alterações no SQL Server. Ele monitora quais scripts de alteração já foram executados e inicia os necessários para atualizar o banco de dados. A biblioteca surgiu do projeto do mecanismo de blog de código aberto no ASP.NET e existe sob a licença MIT, e o código está no GitHub. As migrações são descritas usando o T-SQL.

Quais são as vantagens:

• Suporte para um grande número de DBMSs (MS SQL Server, PstgreSQL, MySQL)
• Como os scripts são escritos em T-SQL, eles parecem bem simples
• Conflitos também são resolvidos usando SQL

Um contras:

• Com toda a variedade de DBMSs suportados, a Oracle não está entre eles.
• Não interage com o ORM
• Escrever scripts T-SQL com canetas não é o nosso objetivo
• A documentação e a comunidade são mais ou menos assim, embora possam não ser necessárias no contexto de gravação de scripts SQL.

RoundhousE


github.com/chucknorris/roundhouse

Essa ferramenta de gerenciamento de migração, distribuída sob a licença Apache 2.0, como a anterior, é executada no mecanismo de migração T-SQL. Aparentemente, os desenvolvedores se concentraram em resolver problemas técnicos relacionados ao suporte ao DBMS, em vez de criar um processo de desenvolvimento confortável.

Prós:

• Suporta o DBMS necessário (incluindo Oracle)

Contras:

• O Oracle (assim como o Access irrelevante para nós) não é suportado no .NET Core, apenas no .NET Full Framework
• Não funciona com ORM
• Existe ainda menos documentação que a ferramenta anterior
• Novamente - as migrações são escritas em scripts

ThinkingHome.Migrator



Uma ferramenta para migração versionada de um esquema de banco de dados para a plataforma .NET Core, distribuída sob a licença MIT. O próprio desenvolvedor escreveu sobre a versão mais recente há quase um ano .

Prós:

• Afiado no .NET Core
• Sequência de ramificações implementada de migrações
• Log 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 ocorre há um ano)
• Falta a geração automática de migrações

Em geral, o projeto parece promissor, principalmente se ele se desenvolver, mas precisávamos tomar uma decisão aqui e agora.

Migrador fluente


github.com/fluentmigrator/fluentmigrator

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 plataforma de migração para .NET, semelhante às migrações do Ruby on Rails. Alterações no esquema do banco de dados são descritas nas classes em C #.

Existem vantagens:

• Suporte para o DBMS necessário
• Suporte ao .NET Core
• Grande comunidade desenvolvida
• Os conflitos de migração são resolvidos sequencialmente - a ordem de execução é indicada para migrações. Além disso, se houver um conflito em torno de uma entidade, ao mesclar o código, sua solução será executada da mesma maneira que no restante do código
• Existem perfis que são executados após uma migração bem-sucedida. E eles podem executar funções de serviço. A última atualização ocorreu há um mês, ou seja, o projeto continua

Quanto aos contras, aqui:

• Falta a geração automática de migrações
• Sem conexão com modelos EF
• Nenhum instantâneo de banco de dados

Qual foi a nossa escolha?

O debate mais acalorado girou em torno de dois parâmetros - geração automática de migrações e resolução sã de conflitos. Outros fatores assustaram muito menos. Como resultado, como resultado da discussão, a equipe decidiu usar o Fluent Migrator no novo projeto. A resolução de conflitos no futuro trará muito mais vantagens.

Conclusões

Obviamente, não existem ferramentas perfeitas. Então tivemos que priorizar nossa "lista de desejos" para uma escolha. No entanto, outros fatores podem ser decisivos para outras equipes e outras tarefas. Esperamos que este artigo ajude você a fazer uma escolha.