Confronto e selezione di sistemi di migrazione dei dati
Il modello dei dati tende a cambiare durante il processo di sviluppo e ad un certo punto non corrisponde più al database. Naturalmente, il database può essere cancellato e quindi l'ORM creerà una nuova versione che corrisponderà al modello, ma questa procedura porterà alla perdita dei dati esistenti. Pertanto, la funzione del sistema di migrazione è garantire che, in seguito a una modifica dello schema, venga sincronizzato con il modello di dati nell'applicazione senza perdere i dati esistenti.
In questo articolo, vorremmo esaminare vari strumenti per la gestione delle migrazioni dei database. Ci auguriamo che questa recensione sia utile agli sviluppatori che si trovano di fronte a una scelta simile.
Compito
La nostra azienda sta attualmente sviluppando attivamente la prossima generazione di prodotti: Docs Security Suite (DSS). La parte server è scritta in .Net Core e Entity Framework Core viene utilizzato come DBMS. Quando progettiamo un'applicazione, utilizziamo l'approccio Code First.
Il modello del dominio dell'applicazione viene creato da più sviluppatori contemporaneamente, ognuno è responsabile della propria parte logica del sistema.
La generazione precedente di DSS utilizzava il classico Entity Framework Migrations (EF 6) come sistema di gestione della migrazione. Tuttavia, si sono accumulate alcune lamentele contro di esso, la principale delle quali è che EF manca di un approccio sensato alla risoluzione dei conflitti di versione. Questo fatto ci disturba ancora quando risolviamo i bug come parte del supporto, quindi abbiamo deciso di considerare opzioni alternative.
Come risultato della discussione, sono stati formati i seguenti requisiti per il sistema di gestione della migrazione:
- Supporto per vari DBMS. Sono richiesti MS SQL Server, PostgreSQL, Oracle, ma è potenzialmente possibile utilizzarne altri
- Lavorare con ORM. Inizialmente era previsto l'utilizzo di EF Core, ma in fase di progettazione eravamo pronti a prendere in considerazione altri ORM
- Generazione automatica delle migrazioni. Tenendo conto dello sviluppo di Code First, vorrei evitare la necessità di “scrivere a mano” le migrazioni
- Conflitti di versione. In un ambiente di sviluppo distribuito, durante la fusione, EF Core può soffrire di conflitti. Questo diventa un problema significativo perché parti diverse dell'applicazione vengono create da sviluppatori diversi, quindi è necessario dedicare molto tempo a ciascuna di esse.
- Documentazione e supporto avanzati. Qui, ci sembra, non è necessaria alcuna spiegazione
- Gratuito. Il criterio è condizionale, poiché i sistemi non sono molto costosi o costosi, ma ideali in termini di praticità, eravamo anche pronti a prenderli in considerazione
Come risultato di una piccola ricerca, sono state trovate le seguenti opzioni, ritenute desiderabili da prendere in considerazione:
- Migrazioni EF Core
- DBup
- RoundhouseE
- ThinkingHome.Migrator
- Migratore fluente
E ora un po' più di dettaglio
Naturalmente questa è stata la prima e principale opzione da scegliere. Uno strumento nativo che funziona fuori dagli schemi senza dover armeggiare con un tamburello. Molta documentazione, ufficiale e non, semplicità, ecc. Tuttavia, le lamentele avanzate sull'EF classico sono abbastanza rilevanti anche per EF Core.
Pertanto, vengono evidenziati i vantaggi per EF Core:
- Supporto Microsoft, documentazione, anche in russo, enorme community
- Generazione automatica delle migrazioni basata su CodeFirst
- Rispetto a EF 6, EF Core non archivia più uno snapshot del database. Quando si usa EF Core in Code First, non è più necessario distribuire un database
- Poiché stiamo partendo da Code First, è possibile effettuare una migrazione a tutti i fornitori di accesso ai dati richiesti
- Per quanto riguarda i provider, è supportato PostgreSQL, è supportato Oracle, ecc. Ecc. e persino MS SQL Server
E anche gli svantaggi:
- La risoluzione dei conflitti è rimasta allo stesso livello. È necessario sequenziare le migrazioni e aggiornare gli snapshot del database
- Dipendenza dai modelli su cui vengono generate le migrazioni
DbUp
DbUp è una libreria .NET installata da NuGet e consente di inviare modifiche a SQL Server. Tiene traccia degli script di modifica già eseguiti ed esegue quelli necessari per aggiornare il database. La libreria è nata da un progetto per un motore di blogging open source su ASP.NET ed esiste con una licenza MIT e il codice è su GitHub. Le migrazioni vengono descritte utilizzando T-SQL.
Quali sono i vantaggi:
- Supporto per un gran numero di DBMS (MS SQL Server, PstgreSQL, MySQL)
- Poiché gli script sono scritti in T-SQL, sembrano abbastanza semplici
- Anche i conflitti vengono risolti utilizzando SQL
E i contro:
- Con tutta la varietà di DBMS supportati, Oracle non è uno di questi
- Non interagisce con l'ORM
- Scrivere script T-SQL a mano non è ciò a cui miravamo
- La documentazione e la community sono così così, anche se in termini di scrittura di script SQL potrebbero non essere necessarie.
RoundhouseE
Questo strumento di gestione della migrazione, distribuito sotto la licenza Apache 2.0, come il precedente, funziona sul motore di migrazione T-SQL. A quanto pare, gli sviluppatori hanno dato priorità alla risoluzione dei problemi tecnici relativi al supporto DBMS, piuttosto che alla creazione di un processo di sviluppo confortevole.
pro:
- Supporta il DBMS necessario (incluso Oracle)
contro:
- Oracle (così come Access, che per noi è irrilevante) non è supportato su .NET Core, solo su .NET Full Framework
- Non funziona con ORM
- C'è ancora meno documentazione rispetto allo strumento precedente
- Ancora una volta: le migrazioni sono scritte da script
ThinkingHome.Migrator
Uno strumento per la migrazione dello schema di database con versione alla piattaforma .NET Core, distribuito con licenza MIT. .
pro:
- Progettato per .NET Core
- Implementata una sequenza ramificata di migrazioni
- Registrazione della migrazione implementata
contro:
- Ultimo aggiornamento un anno fa. Apparentemente il progetto non è supportato
- Non supportato da Oracle (l'articolo afferma che ciò è dovuto alla mancanza di un'implementazione stabile per .NET Core, ma questo è un anno fa)
- Nessuna generazione automatica delle migrazioni
Nel complesso il progetto sembra promettente, soprattutto se dovesse svilupparsi, ma dovevamo prendere una decisione qui e ora.
Migratore fluente
Lo strumento di migrazione più popolare con un vasto esercito di fan. Distribuito sotto la licenza Apache 2.0. Come indicato nella descrizione, si tratta di un framework di migrazione per .NET, simile a Ruby on Rails Migrations. Le modifiche allo schema del database sono descritte nelle classi C#.
Ci sono vantaggi qui:
- Supporto per il DBMS richiesto
- Supporto .NET Core
- Grande comunità sviluppata
- I conflitti tra le migrazioni vengono risolti in sequenza: viene specificato l'ordine di esecuzione delle migrazioni. Inoltre, se si verifica un conflitto attorno a un'entità, quando si uniscono i codici, viene risolto come nel resto del codice
- Esistono profili che vengono eseguiti dopo una migrazione riuscita. E possono svolgere funzioni di servizio: l'ultimo aggiornamento è stato un mese fa, cioè il progetto è vivo
Per quanto riguarda gli svantaggi, eccoli qui:
- Nessuna generazione automatica delle migrazioni
- Nessuna connessione con i modelli EF
- Nessuno snapshot del database
Qual è stata la nostra scelta?
Gli accesi dibattiti ruotavano attorno a due parametri: la generazione automatica delle migrazioni e la sana risoluzione dei conflitti. Altri fattori erano molto meno spaventosi. Di conseguenza, sulla base dei risultati della discussione, il team ha deciso di utilizzare Fluent Migrator nel nuovo progetto. Perché la risoluzione dei conflitti in futuro porterà molti più vantaggi.
risultati
Naturalmente non esistono strumenti perfetti. Quindi abbiamo dovuto dare la priorità ai nostri “desideri” per fare una scelta. Tuttavia, per altri team e altri compiti, altri fattori possono essere decisivi. Speriamo che questo articolo ti aiuti a fare una scelta.
Fonte: habr.com