Sammenligning og valg af datamigreringssystemer
Datamodellen har en tendens til at ændre sig under udviklingsprocessen, og på et tidspunkt svarer den ikke længere til databasen. Databasen kan selvfølgelig slettes, og så vil ORM oprette en ny version, der matcher modellen, men denne procedure vil føre til tab af eksisterende data. Migrationssystemets funktion er således at sikre, at det som følge af en skemaændring synkroniseres med datamodellen i applikationen uden at miste eksisterende data.
I denne artikel vil vi gerne se på forskellige værktøjer til styring af databasemigreringer. Vi håber, at denne anmeldelse vil være nyttig for udviklere, der står over for et lignende valg.
Opgave
Vores virksomhed er i øjeblikket aktivt ved at udvikle den næste generation af produkter - Docs Security Suite (DSS). Serverdelen er skrevet i .Net Core, og Entity Framework Core bruges som DBMS. Når vi designer en applikation, bruger vi Code First-tilgangen.
Applikationsdomænemodellen er skabt af flere udviklere på samme tid - hver er ansvarlig for deres egen logiske del af systemet.
Den tidligere generation af DSS brugte den klassiske Entity Framework Migrations (EF 6) som migrationsstyringssystem. Der er dog ophobet nogle klager mod det, hvoraf den vigtigste er, at EF mangler en fornuftig tilgang til at løse versionskonflikter. Dette faktum forstyrrer os stadig, når vi fikser fejl som en del af supporten, så vi besluttede at overveje alternative muligheder.
Som et resultat af diskussionen blev følgende krav til migrationsstyringssystemet dannet:
- Support til forskellige DBMS'er. MS SQL Server, PostgreSQL, Oracle er påkrævet, men det er potentielt muligt at bruge andre
- Arbejder med ORM. Oprindeligt var det planlagt at bruge EF Core, men på designstadiet var vi klar til at overveje andre ORM'er
- Autogenerering af migrationer. Under hensyntagen til udviklingen af Code First vil jeg gerne undgå behovet for at "håndskrive" migreringer
- Versionskonflikter. I et distribueret udviklingsmiljø kan EF Core lide af konflikter ved sammenlægning. Dette bliver et betydeligt problem, fordi forskellige dele af applikationen er skabt af forskellige udviklere, så du skal bruge meget tid på hver
- Avanceret dokumentation og support. Her, forekommer det os, er der ingen forklaring nødvendig
- Gratis. Kriteriet er betinget, da systemer ikke er særlig dyre eller dyre, men ideelle i bekvemmelighed, var vi også klar til at overveje
Som et resultat af lidt forskning blev følgende muligheder fundet og fundet ønskelige til overvejelse:
- EF Core Migrations
- DBup
- RoundhouseE
- ThinkingHome.Migrator
- Flydende migrator
Og nu lidt flere detaljer
Naturligvis var dette den første og vigtigste mulighed at vælge. Et indfødt instrument, der fungerer ud af æsken uden at rode rundt med en tamburin. En stor mængde dokumentation, officiel og ikke så, enkelhed osv. Men klagerne over klassisk EF er også ret relevante for EF Core.
Således fremhæves fordelene ved EF Core:
- Microsoft support, dokumentation, herunder på russisk, stort fællesskab
- Autogenerering af migrationer baseret på CodeFirst
- Sammenlignet med EF 6 gemmer EF Core ikke længere et øjebliksbillede af databasen. Når du arbejder med EF Core i Code First, er det ikke længere nødvendigt at implementere en database
- Da vi danser fra Code First, er det muligt at udføre én migrering til alle nødvendige dataadgangsudbydere
- Med hensyn til udbydere understøttes PostgreSQL, Oracle understøttes osv. osv., og endda MS SQL Server
Og også ulemperne:
- Konfliktløsning forblev på samme niveau. Det er nødvendigt at sekvensere migrationer og opdatere database-øjebliksbilleder
- Afhængighed af de modeller, som migrationerne genereres på
DbUp
DbUp er et .NET-bibliotek, der er installeret af NuGet og hjælper med at skubbe ændringer til SQL Server. Den holder styr på, hvilke ændringsscripts der allerede er blevet udført og kører dem, der er nødvendige for at opdatere databasen. Biblioteket voksede ud af et projekt for en open source blogging-motor på ASP.NET og eksisterer under en MIT-licens, og koden er på GitHub. Migreringer beskrives ved hjælp af T-SQL.
Hvad er fordelene:
- Understøttelse af et stort antal DBMS (MS SQL Server, PstgreSQL, MySQL)
- Da scripts er skrevet i T-SQL, ser de ret simple ud
- Konflikter løses også ved hjælp af SQL
Og ulemperne:
- Med alle de mange forskellige understøttede DBMS'er er Oracle ikke en af dem
- Interagerer ikke med ORM
- At skrive T-SQL-scripts i hånden er ikke det, vi sigtede efter
- Dokumentationen og fællesskabet er halvdårlige, selvom det måske ikke er nødvendigt med hensyn til at skrive SQL-scripts.
RoundhouseE
Dette migrationsstyringsværktøj, distribueret under Apache 2.0-licensen, som den forrige, kører på T-SQL-migreringsmotoren. Tilsyneladende prioriterede udviklerne at løse tekniske problemer vedrørende DBMS-support frem for at skabe en behagelig udviklingsproces.
Teknikere:
- Understøtter det nødvendige DBMS (inklusive Oracle)
Ulemper:
- Oracle (såvel som Access, som er irrelevant for os) understøttes ikke på .NET Core, kun på .NET Full Framework
- Virker ikke med ORM
- Der er endnu mindre dokumentation end det tidligere værktøj
- Igen - migreringer er skrevet af scripts
ThinkingHome.Migrator
Et værktøj til migrering af versionsbaseret databaseskema til .NET Core-platformen, distribueret under MIT-licensen. .
Teknikere:
- Designet til .NET Core
- Implementerede en forgrenende sekvens af migrationer
- Implementeret migrationslogning
Ulemper:
- Sidst opdateret for et år siden. Tilsyneladende er projektet ikke støttet
- Ikke understøttet af Oracle (artiklen siger, at dette skyldes manglen på en stabil implementering til .NET Core - men det er et år siden)
- Ingen automatisk generering af migrationer
Samlet set ser projektet lovende ud, især hvis det skulle udvikle sig, men vi skulle tage en beslutning her og nu.
Flydende migrator
Det mest populære migrationsværktøj med en stor hær af fans. Distribueret under Apache 2.0-licensen. Som angivet i beskrivelsen er det en migrationsramme for .NET, der ligner Ruby on Rails Migrations. Ændringer i databaseskemaet er beskrevet i C#-klasser.
Der er fordele her:
- Support til påkrævet DBMS
- .NET Core support
- Stort udviklet samfund
- Konflikter mellem migreringer løses sekventielt - rækkefølgen for udførelse af migreringer er angivet. Desuden, hvis der opstår en konflikt omkring en enhed, når koden flettes, løses den på samme måde som i resten af koden
- Der er profiler, der udføres efter en vellykket migrering. Og de kan bære servicefunktioner. Sidste opdatering var for en måned siden, det vil sige, at projektet er i live
Hvad angår minusserne, her er de:
- Ingen automatisk generering af migrationer
- Ingen forbindelse med EF-modeller
- Ingen database-øjebliksbilleder
Hvad var vores valg?
De ophedede debatter drejede sig om to parametre - automatisk generering af migrationer og fornuftig løsning af konflikter. Andre faktorer var meget mindre skræmmende. Som et resultat, baseret på resultaterne af diskussionen, besluttede teamet at bruge Fluent Migrator i det nye projekt. Fordi at løse konflikter i fremtiden vil give meget flere fordele.
Fund
Selvfølgelig er der ingen perfekte værktøjer. Så vi var nødt til at prioritere vores "ønsker" for at træffe et valg. For andre teams og andre opgaver kan andre faktorer dog være afgørende. Vi håber, at denne artikel vil hjælpe dig med at træffe et valg.
Kilde: www.habr.com