Sammenligning og valg av datamigrasjonssystemer
Datamodellen har en tendens til å endre seg under utviklingsprosessen, og på et tidspunkt samsvarer den ikke lenger med databasen. Selvfølgelig kan databasen slettes, og da vil ORM lage en ny versjon som vil matche modellen, men denne prosedyren vil føre til tap av eksisterende data. Dermed er funksjonen til migreringssystemet å sikre at det, som følge av en skjemaendring, synkroniseres med datamodellen i applikasjonen uten å miste eksisterende data.
I denne artikkelen vil vi se på ulike verktøy for å administrere databasemigreringer. Vi håper denne anmeldelsen vil være nyttig for utviklere som står overfor et lignende valg.
Oppgave
Vårt firma utvikler for tiden aktivt neste generasjons produkt – Docs Security Suite (DSS). Serverdelen er skrevet i .Net Core, og Entity Framework Core brukes som DBMS. Når vi designer en applikasjon, bruker vi Code First-tilnærmingen.
Applikasjonsdomenemodellen lages av flere utviklere samtidig - hver er ansvarlig for sin egen logiske del av systemet.
Den forrige generasjonen av DSS brukte den klassiske Entity Framework Migrations (EF 6) som migrasjonsstyringssystem. Noen klager har imidlertid samlet seg mot det, den viktigste er at EF mangler en fornuftig tilnærming til å løse versjonskonflikter. Dette faktum opprører oss fortsatt når vi fikser feil som en del av støtten, så vi bestemte oss for å vurdere alternative alternativer.
Som et resultat av diskusjonen ble følgende krav til migrasjonsstyringssystemet dannet:
- Støtte for ulike DBMS-er. MS SQL Server, PostgreSQL, Oracle kreves, men det er potensielt mulig å bruke andre
- Jobber med ORM. Opprinnelig var det planlagt å bruke EF Core, men på designstadiet var vi klare til å vurdere andre ORMer
- Automatisk generering av migrasjoner. Med tanke på utviklingen av Code First, vil jeg unngå behovet for å "håndskrive" migrasjoner
- Versjonskonflikter. I et distribuert utviklingsmiljø, ved sammenslåing, kan EF Core lide av konflikter. Dette blir et betydelig problem fordi forskjellige deler av applikasjonen er laget av forskjellige utviklere, så du må bruke mye tid på hver
- Avansert dokumentasjon og støtte. Her ser det ut til at det ikke trengs noen forklaring
- Gratis. Kriteriet er betinget, siden systemer ikke er veldig dyre eller dyre, men ideelle i bekvemmelighet, var vi også klare til å vurdere
Som et resultat av litt forskning ble følgende alternativer funnet og funnet ønskelige for vurdering:
- EF Core Migrations
- DBup
- RoundhouseE
- ThinkingHome.Migrator
- Flytende migrator
Og nå litt mer detalj
Naturligvis var dette det første og viktigste alternativet å velge. Et innfødt instrument som fungerer ut av esken uten å fikle med en tamburin. En stor mengde dokumentasjon, offisiell og ikke så, enkelhet, etc. Men klagene på klassisk EF er også ganske relevante for EF Core.
Dermed blir fordelene for EF Core fremhevet:
- Microsoft-støtte, dokumentasjon, inkludert på russisk, stort fellesskap
- Autogenerering av migrasjoner basert på CodeFirst
- Sammenlignet med EF 6, lagrer ikke lenger EF Core et øyeblikksbilde av databasen. Når du arbeider med EF Core i Code First, er det ikke lenger nødvendig å distribuere en database
- Siden vi danser fra Code First, er det mulig å gjennomføre én migrering til alle nødvendige datatilgangsleverandører
- Når det gjelder leverandører, støttes PostgreSQL, Oracle støttes, etc., etc., og til og med MS SQL Server
Og også ulempene:
- Konfliktløsning holdt seg på samme nivå. Det er nødvendig å sekvensere migrasjoner og oppdatere øyeblikksbilder av databasen
- Avhengighet av modellene som migreringene genereres på
DbUp
DbUp er et .NET-bibliotek som er installert av NuGet og hjelper til med å pushe endringer til SQL Server. Den holder styr på hvilke endringsskript som allerede er utført og kjører de som er nødvendige for å oppdatere databasen. Biblioteket vokste ut av et prosjekt for en åpen kildekode blogging-motor på ASP.NET og eksisterer under en MIT-lisens, og koden er på GitHub. Migreringer er beskrevet ved hjelp av T-SQL.
Hva er fordelene:
- Støtte for et stort antall DBMS (MS SQL Server, PstgreSQL, MySQL)
- Siden skriptene er skrevet i T-SQL, ser de ganske enkle ut
- Konflikter løses også ved hjelp av SQL
Og ulempene:
- Med alle de forskjellige støttede DBMS-er, er ikke Oracle en av dem
- Samhandler ikke med ORM
- Å skrive T-SQL-skript for hånd er ikke det vi siktet til
- Dokumentasjonen og fellesskapet er ujevne, selv om de kanskje ikke er nødvendige når det gjelder å skrive SQL-skript.
RoundhouseE
Dette migreringsadministrasjonsverktøyet, distribuert under Apache 2.0-lisensen, som den forrige, kjører på T-SQL-migreringsmotoren. Tilsynelatende prioriterte utviklerne å løse tekniske problemer angående DBMS-støtte, fremfor å lage en komfortabel utviklingsprosess.
Pros:
- Støtter nødvendig DBMS (inkludert Oracle)
Cons:
- Oracle (samt Access, som er irrelevant for oss) støttes ikke på .NET Core, kun på .NET Full Framework
- Fungerer ikke med ORM
- Det er enda mindre dokumentasjon enn det forrige verktøyet
- Igjen – migreringer er skrevet av skript
ThinkingHome.Migrator
Et verktøy for versjonert databaseskjemamigrering til .NET Core-plattformen, distribuert under MIT-lisensen. .
Pros:
- Designet for .NET Core
- Implementerte en forgrenende sekvens av migrasjoner
- Implementerte migrasjonslogging
Cons:
- Sist oppdatert for et år siden. Prosjektet er tydeligvis ikke støttet
- Støttes ikke av Oracle (artikkelen sier at dette skyldes mangelen på en stabil implementering for .NET Core - men dette er et år siden)
- Ingen automatisk generering av migrasjoner
Totalt sett ser prosjektet lovende ut, spesielt hvis det skulle utvikle seg, men vi måtte ta en beslutning her og nå.
Flytende migrator
Det mest populære migrasjonsverktøyet med en stor hær av fans. Distribuert under Apache 2.0-lisensen. Som det fremgår av beskrivelsen, er det et migrasjonsrammeverk for .NET, som ligner på Ruby on Rails Migrations. Endringer i databaseskjemaet er beskrevet i C#-klasser.
Det er fordeler her:
- Støtte for nødvendig DBMS
- .NET Core-støtte
- Stort utviklet samfunn
- Konflikter mellom migreringer løses sekvensielt – rekkefølgen for utførelse av migreringer er spesifisert. I tillegg, hvis det oppstår en konflikt rundt en enhet, ved sammenslåing av koden, løses den på samme måte som i resten av koden
- Det er profiler som kjøres etter en vellykket migrering. Og de kan bære servicefunksjoner.Siste oppdatering var for en måned siden, det vil si at prosjektet lever
Når det gjelder minusene, her er de:
- Ingen automatisk generering av migrasjoner
- Ingen forbindelse med EF-modeller
- Ingen øyeblikksbilder av databasen
Hva var vårt valg?
De heftige debattene dreide seg om to parametere – automatisk generering av migrasjoner og fornuftig løsning av konflikter. Andre faktorer var mye mindre skremmende. Som et resultat, basert på resultatene av diskusjonen, bestemte teamet seg for å bruke Fluent Migrator i det nye prosjektet. Fordi å løse konflikter i fremtiden vil gi mye flere fordeler.
Funn
Selvfølgelig er det ingen perfekte verktøy. Så vi måtte prioritere våre "ønsker" for å ta et valg. For andre team og andre oppgaver kan imidlertid andre faktorer være avgjørende. Vi håper denne artikkelen vil hjelpe deg å ta et valg.
Kilde: www.habr.com