Confronto e scelta dei sistemi di migrazione dei dati
Il modello dei dati in fase di sviluppo è soggetto a cambiamenti e a un certo punto può smettere di corrispondere al database. Certamente, è possibile eliminare il DB, e in tal caso l'ORM creerà una nuova versione che sarà in linea con il modello, ma questa procedura porterà alla perdita dei dati esistenti. Pertanto, la funzione del sistema di migrazione è quella di sincronizzare la scheda con il modello dei dati nell'applicazione a seguito di cambiamenti, senza perdere i dati esistenti.
In questo articolo, desideriamo esaminare vari strumenti per la gestione delle migrazioni dei database. Speriamo che questa panoramica sia utile per gli sviluppatori che si trovano di fronte a questa scelta.
Compito
Nella nostra azienda stiamo attualmente sviluppando attivamente la prossima generazione del prodotto – Docs Security Suite (DSS). La parte server è scritta in .Net Core e il database utilizzato è Entity Framework Core. Durante la progettazione dell'applicazione, adottiamo l'approccio Code First.
Il modello a dominio dell'applicazione è creato contemporaneamente da più sviluppatori, ognuno dei quali è responsabile per la propria parte logica del sistema.
Nella precedente generazione di DSS, il sistema di gestione delle migrazioni utilizzava le classiche Migrations di Entity Framework (EF 6). Tuttavia, ci sono state alcune lamentele su di esso, la principale delle quali riguardava l'assenza di un approccio ragionevole alla risoluzione dei conflitti di versione in EF. Questo fatto ci preoccupa ancora durante il bug fixing nell'ambito del supporto, quindi è stata presa la decisione di esplorare opzioni alternative.
A seguito della discussione, sono emerse le seguenti esigenze per il sistema di gestione delle migrazioni:
- Supporto per diversi DBMS. È necessario MS SQL Server, PostgreSQL, Oracle, ma è potenzialmente possibile l'uso di altri.
- Collaborazione con ORM. Inizialmente si prevedeva di utilizzare EF Core, ma durante la fase di progettazione eravamo pronti a considerare anche altri ORM.
- Generazione automatica delle migrazioni. Data la progettazione Code First, ci piacerebbe evitare di 'scrivere a mano' le migrazioni.
- Conflitti di versione. Nello sviluppo distribuito, durante il merging, EF Core può incorrere in conflitti. Questo diventa un problema significativo, dato che diverse parti dell'applicazione vengono create da sviluppatori diversi, portando a una notevole perdita di tempo su ciascun conflitto.
- Documentazione e supporto avanzati. Qui, non servono ulteriori spiegazioni.
- Gratuità. Questo criterio è soggettivo, poiché siamo anche pronti a considerare sistemi economici o costosi ma eccellenti in termini di usabilità.
Dopo una breve ricerca, sono stati trovati e considerati desiderabili i seguenti opzioni:
- Migrazioni di EF Core
- DBup
- RoundhousE
- ThinkingHome.Migrator
- Fluent Migrator
E ora in modo più dettagliato
Naturalmente, questa è stata la prima e principale opzione da considerare. Uno strumento nativo, funzionante out-of-the-box senza alcun passaggio complicato. Ampia documentazione, ufficiale e non, semplicità, ecc. Tuttavia, le critiche mosse a EF classico sono del tutto valide anche per EF Core.
Pertanto, EF Core presenta i seguenti vantaggi:
- Supporto Microsoft, documentazione, compresa quella in russo, e una vasta comunità.
- Generazione automatica delle migrazioni basata su Code First
- A differenza di EF 6, in EF Core non viene più memorizzato un'istantanea del database. Quando si utilizza EF Core in Code First, non è più necessario distribuire il database.
- Poiché partiamo da Code First, c'è la possibilità di gestire una migrazione per tutti i fornitori di accesso ai dati necessari.
- Per quanto riguarda i fornitori, sono supportati sia PostgreSQL che Oracle, ecc., ecc., e addirittura – MS SQL Server 😊
E ci sono anche svantaggi:
- La risoluzione dei conflitti è rimasta allo stesso livello. È necessario stabilire una sequenza di migrazioni e aggiornare le istantanee del database.
- Dipendenza dai modelli su cui sono state generate le migrazioni.
DbUp
DbUp è una libreria .NET che si installa tramite NuGet e aiuta a applicare modifiche su SQL Server. Monitora quali script di modifica sono già stati eseguiti e avvia quelli necessari per aggiornare il database. La libreria è nata da un progetto di motore di blogging open source su ASP.NET e esiste sotto licenza MIT, con il codice disponibile su GitHub. Le migrazioni sono descritte utilizzando T-SQL.
Quali sono i vantaggi:
- Supporto per un gran numero di DBMS (MS SQL Server, PostgreSQL, MySQL)
- Poiché gli script sono scritti in T-SQL, appaiono piuttosto semplici.
- I conflitti possono essere risolti anche con SQL
E i problemi:
- Nonostante la varietà di DBMS supportati, Oracle non è incluso
- Non interagisce con ORM
- Scrivere script in T-SQL 'a mano' non è ciò a cui aspiriamo
- La documentazione e la comunità sono piuttosto scarse, anche se per scrivere script SQL potrebbero non essere necessarie.
RoundhousE
Questo strumento di gestione delle migrazioni, distribuito con licenza Apache 2.0, come il precedente, funziona sul motore delle migrazioni T-SQL. A quanto pare, gli sviluppatori si sono concentrati sulla risoluzione dei problemi tecnici relativi al supporto dei DBMS, piuttosto che sulla creazione di un processo di sviluppo confortevole.
Vantaggi:
- Supporta i DBMS necessari (incluso Oracle)
Contro:
- Oracle (e anche Access, che non ci interessa) non è supportato su .NET Core, solo su .NET Full Framework
- Non funziona con ORM
- Ci sono ancora meno documentazione rispetto allo strumento precedente
- Ancora una volta, le migrazioni sono scritte con script
ThinkingHome.Migrator
Strumento per la migrazione versionata dello schema di database per la piattaforma .NET Core, distribuito con licenza MIT. .
Vantaggi:
- Ottimizzato per .NET Core
- È implementata una sequenza di migrazioni ramificata
- È stata implementata la registrazione delle migrazioni
Contro:
- Ultimo aggiornamento - un anno fa. A quanto pare, il progetto non è più supportato
- Oracle non è supportato (nell'articolo si sottolinea che ciò è dovuto alla mancanza di un'implementazione stabile per .NET Core - ma questo risale a un anno fa)
- Mancanza di generazione automatica delle migrazioni
In generale, il progetto sembra promettente, soprattutto se fosse stato sviluppato, ma dovevamo prendere decisioni qui e ora.
Fluent Migrator
Il più popolare strumento di migrazione, con un vasto seguito di fan. È distribuito sotto licenza Apache 2.0. Come indicato nella descrizione, è una piattaforma di migrazione per .NET, simile a Ruby on Rails Migrations. Le modifiche allo schema del database sono descritte in classi in C#.
Ci sono vantaggi:
- Supporto per i DBMS necessari
- Supporto per .NET Core
- Una grande comunità attiva
- I conflitti di migrazione vengono risolti in modo sequenziale - per le migrazioni viene specificato l'ordine di esecuzione. Inoltre, se si verifica un conflitto su un'entità, durante il merging del codice, la sua risoluzione avviene come nel resto del codice
- Ci sono profili che vengono eseguiti dopo una migrazione riuscita e possono includere funzioni di servizio. L'ultimo aggiornamento risale a un mese fa, il che significa che il progetto è attivo.
Quanto ai lati negativi, qui ci sono:
- Mancanza di generazione automatica delle migrazioni
- Mancanza di connessione con i modelli EF
- Nessun backup del database
Qual è stata la nostra scelta?
Le discussioni più accese si sono concentrate su due parametri: l'autogenerazione delle migrazioni e una soluzione ragionevole ai conflitti. Altri fattori preoccupavano molto meno. Alla fine, dopo una discussione, il team ha deciso di utilizzare Fluent Migrator per il nuovo progetto. Perché la risoluzione dei conflitti porterà nel lungo periodo un numero maggiore di benefici.
Conclusioni
Naturalmente, non esistono strumenti perfetti. Abbiamo dovuto stabilire delle priorità nelle nostre "preferenze". Tuttavia, per altri team e altri compiti, potrebbero esserci fattori decisivi diversi. Speriamo che questo articolo possa aiutarvi a fare una scelta.
Fonte: habr.com
