Confronto e scelta dei sistemi di migrazione dei dati
Il modello dei dati in fase di sviluppo ha la proprietà di cambiare, e a un certo punto smette di corrispondere al database. Certamente, il database può essere eliminato, e allora l'ORM creerà una nuova versione che corrisponderà al modello, ma tale procedura porterà alla perdita dei dati esistenti. Pertanto, la funzione del sistema di migrazione si riduce a sincronizzare lo schema modificato con il modello dei dati nell'app senza perdere i dati esistenti.
In questo articolo ci piacerebbe esaminare diversi strumenti per la gestione delle migrazioni dei database. Speriamo che questa panoramica sia utile per i programmatori che si trovano di fronte a una simile scelta.
Compito
Attualmente nella nostra azienda si sta attivamente sviluppando la prossima generazione del prodotto – Docs Security Suite (DSS). La parte server è scritta in .Net Core e come DBMS utilizziamo di conseguenza Entity Framework Core. Nella progettazione dell'app, utilizziamo l'approccio Code First.
Il modello di dominio dell'applicazione è creato contemporaneamente da più sviluppatori, ognuno dei quali è responsabile della propria parte logica del sistema.
Nella precedente generazione di DSS, per la gestione delle migrazioni è stata utilizzata la classica Entity Framework Migrations (EF 6). Tuttavia, su di essa si sono accumulate alcune lamentele, la principale delle quali riguardava l'assenza in EF di un approccio ragionevole alla risoluzione dei conflitti di versione. Questo fatto ci rattrista ancora durante il bug fixing nell'ambito del supporto, quindi è stata presa la decisione di esplorare alternative.
Dopo una discussione, si sono definiti i seguenti requisiti per il sistema di gestione delle migrazioni:
- Supporto per diversi DBMS. MS SQL Server, PostgreSQL, Oracle sono obbligatori, ma è potenzialmente possibile utilizzare anche altri.
- Lavoro con ORM. Inizialmente si prevedeva l'uso di EF Core, ma durante la fase di progettazione eravamo aperti a considerare anche altri ORM.
- Autogenerazione delle migrazioni. Considerando lo sviluppo Code First, vorremmo evitare la necessità di "scrivere a mano" le migrazioni.
- Conflitti di versione. In un contesto di sviluppo distribuito, durante il merging EF Core può andare in crisi a causa dei conflitti. Questo diventa un problema significativo, poiché le diverse parti dell'applicazione vengono create da sviluppatori diversi, e perciò si perde molto tempo per ogni
- Documentazione avanzata e supporto. Qui, ci sembra, non siano necessarie spiegazioni.
- Gratuità. Il criterio è soggettivo, poiché sistemi non molto costosi o costosi, ma ideali in termini di comodità, siamo comunque stati disposti a considerare.
A seguito di una piccola ricerca sono stati trovati e considerati desiderabili i seguenti opzioni:
- Migrazioni EF Core
- DBup
- RoundhousE
- ThinkingHome.Migrator
- Fluent Migrator
E ora un po' più nel dettaglio
Naturalmente, questa è stata la prima e principale opzione da considerare. Strumento nativo, funzionante 'out of the box' senza alcun rito. Un'enorme quantità di documentazione, ufficiale e non, semplicità, ecc. Tuttavia, le critiche rivolte al classico EF sono perfettamente valide anche per EF Core.
In questo modo, per EF Core sono stati evidenziati i vantaggi:
- Supporto Microsoft, documentazione, anche in russo, enorme comunità
- Autogenerazione di migrazioni basate su CodeFirst
- Rispetto a EF 6, in EF Core ora non viene conservata una copia del database. Lavorando con EF Core in Code First, ora non è necessario distribuire il database.
- Poiché partiamo da Code First, c'è la possibilità di gestire una migrazione per tutti i fornitori di accesso ai dati richiesti.
- Per quanto riguarda i fornitori, sono supportati sia PostgreSQL che Oracle, e così via, e persino – MS SQL Server 😊.
E anche svantaggi:
- La risoluzione dei conflitti è rimasta allo stesso livello. È necessario stabilire una sequenza di migrazioni e aggiornare le copie del database.
- Dipendenza dai modelli da cui sono state generate le migrazioni.
DbUp
DbUp è una libreria .NET, installata tramite NuGet, che aiuta ad applicare le modifiche al SQL Server. Tiene traccia di quali script di modifica sono già stati eseguiti e esegue quelli necessari per aggiornare il database. La libreria è nata da un progetto di motore blog open source in ASP.NET e esiste sotto licenza MIT, con codice disponibile su GitHub. Le migrazioni sono descritte usando T-SQL.
Quali sono qui 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 sono risolti anche tramite SQL.
E gli svantaggi:
- Nonostante la varietà di DBMS supportati, Oracle non è incluso.
- Non interagisce con ORM.
- Scrivere script in T-SQL 'a mano' non è ciò a cui aspiravamo.
- La documentazione e la community sono un po' scarse, anche se nella scrittura di script SQL potrebbero non essere necessarie.
RoundhousE
Questo strumento di gestione delle migrazioni, distribuito sotto licenza Apache 2.0, come il precedente, funziona sul motore di migrazione 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.
Pro:
- Supporta i DBMS necessari (incluso Oracle)
Contro:
- Oracle (e anche Access, che non è rilevante per noi) non è supportato su .NET Core, ma solo su .NET Full Framework.
- Non funziona con ORM
- La documentazione è ancora più limitata rispetto al precedente strumento.
- Ancora una volta: le migrazioni vengono scritte con script.
ThinkingHome.Migrator
Strumento per la migrazione versionata dello schema del database per la piattaforma .NET Core, distribuito sotto licenza MIT. .
Pro:
- Ottimizzato per .NET Core.
- È stata 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.
- Non supporta Oracle (nell'articolo si afferma che ciò è dovuto all'assenza di un'implementazione stabile per .NET Core, anche se questo è un problema di un anno fa).
- Manca l'autogenerazione delle migrazioni.
In generale, il progetto appare promettente, soprattutto se si sarebbe sviluppato, ma dovevamo prendere una decisione qui e ora.
Fluent Migrator
Strumento di migrazione più popolare, con un grande 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 DB sono descritte in classi in C#.
Ci sono vantaggi:
- Supporto per i DBMS necessari.
- Supporto per .NET Core.
- Grande comunità sviluppata.
- I conflitti di migrazione vengono risolti in modo sequenziale: alle migrazioni viene assegnato un ordine di esecuzione. Inoltre, se si verifica un conflitto relativo a un'entità, la sua risoluzione durante la fusione del codice avviene allo stesso modo del resto del codice.
- Ci sono profili che vengono eseguiti dopo il completamento con successo della migrazione e possono contenere funzioni di servizio. L'ultimo aggiornamento è stato un mese fa, quindi il progetto è attivo.
Per quanto riguarda gli svantaggi, ci sono:
- Manca l'autogenerazione delle migrazioni.
- Manca il collegamento con i modelli EF.
- Nessuno snapshot del DB.
Qual è stata la nostra scelta?
I dibattiti più accesi si sono sviluppati attorno a due parametri: l'autogenerazione delle migrazioni e una gestione ragionevole dei conflitti. Altri fattori spaventavano molto meno. Alla fine, a seguito delle discussioni, il team ha deciso di utilizzare Fluent Migrator per il nuovo progetto. La gestione dei conflitti porterà infatti in futuro un numero considerevole di vantaggi.
Conclusioni
Naturalmente, non esistono strumenti perfetti. Dobbiamo quindi mettere in ordine di priorità le nostre "voglie" per fare una scelta. Tuttavia, per altri team e altre attività potrebbero risultare decisivi fattori diversi. Speriamo che questo articolo vi aiuti a fare la vostra scelta.
Fonte: habr.com
