Sammenligning og valg af datamigrationssystemer
Datamodellen i udviklingsprocessen har en tendens til at ændre sig, og på et tidspunkt stopper den med at svare til databasen. Selvfølgelig kan databasen slettes, og så vil ORM oprette en ny version, der svarer til modellen, men en sådan procedure vil føre til tab af eksisterende data. Dermed handler migrationssystemets funktion om at synkronisere skemaet med datamodellen i applikationen ved ændringer uden at miste eksisterende data.
I denne artikel ønsker vi at se på forskellige værktøjer til styring af database-migrationer. Vi håber, at denne oversigt vil være nyttig for udviklere, der står over for dette valg.
Regler for godkendelse af merge-requests
I vores virksomhed er vi i øjeblikket i aktiv udvikling af næste generation af produktet – Docs Security Suite (DSS). Serverdelen skrives i .Net Core, og som DBMS anvendes tilsvarende Entity Framework Core. Når vi designer applikationen, bruger vi tilgang til Code First.
Domænemodellen for applikationen oprettes af flere udviklere samtidigt – hver især ansvarlig for deres logiske del af systemet.
I den tidligere generation af DSS blev den klassiske Entity Framework Migrations (EF 6) anvendt som migrationsstyringssystem. Dog er der opstået nogle kritikpunkter, hvoraf det primære er, at der ikke i EF findes et ordentligt system til konfliktløsning af versioner. Dette faktum generer os stadig under fejlretning i forbindelse med support, og derfor blev det besluttet at overveje alternative løsninger.
I resultatet af diskussionen blev følgende krav til migrationsstyringssystemet formuleret:
- Understøttelse af forskellige DBMS. MS SQL Server, PostgreSQL, Oracle er obligatoriske, men det er potentielt muligt at bruge andre.
- Arbejder med ORM. Det var oprindeligt meningen at bruge EF Core, men i designfasen var vi åbne for at overveje andre ORM'er.
- Autogenerering af migrationer. I betragtning af udviklingen af Code First ønsker vi at undgå 'håndskrevne' migrationer.
- Versionskonflikter. I forhold til distribueret udvikling kan EF Core fejle på grund af konflikter under merging. Dette bliver et væsentligt problem, da forskellige dele af applikationen skabes af forskellige udviklere, hvilket resulterer i, at der går meget tid på hver enkelt.
- Omfattende dokumentation og support. Her virker forklaringer som overflødige.
- Gratis. Kriteriet er relativt, da vi også er åbne for attraktive systemer, der ikke er alt for dyre.
Som resultat af en lille undersøgelse blev følgende muligheder fundet og anset for ønskelige til overvejelse:
- EF Core Migrations
- DBup
- RoundhousE
- ThinkingHome.Migrator
- Fluent Migrator
Og nu lidt mere detaljeret
Dette var naturligvis det første og primære valg. Et indbygget værktøj, der fungerer ud af boksen uden nogen besvær. En stor mængde dokumentation, både officiel og uofficiel, enkelhed osv. Dog er de kritikpunkter, der blev rejst mod den klassiske EF, også relevante for EF Core.
Dermed kan fordelene ved EF Core opsummeres:
- Microsoft-support, dokumentation, også på russisk, et stort fællesskab.
- Automatisk generering af migrationer baseret på CodeFirst.
- I forhold til EF 6 opbevares der nu ikke længere snapshots af databasen i EF Core. Når der arbejdes med EF Core med Code First, er det nu ikke nødvendigt at implementere databasen.
- Da vi tager udgangspunkt i Code First, er der mulighed for at føre én migration for alle nødvendige datadivertører.
- Hvad angår datadivertører, understøttes både PostgreSQL, Oracle osv., og selv – MS SQL Server.
Og derudover er der også ulemper:
- Håndteringen af konflikter er forblevet på samme niveau. Det er nødvendigt at etablere en sekvens af migrationer og opdatere snapshots af databasen.
- Afhængighed af de modeller, som migrationerne blev genereret ud fra.
DbUp
DbUp er et .NET-bibliotek, der installeres via NuGet og hjælper med at anvende ændringer på SQL Server. Det holder styr på, hvilke ændringsscripts der allerede er udført, og kører dem, der er nødvendige for at opdatere databasen. Biblioteket er vokset ud af et open source blog-motor projekt på ASP.NET og findes under MIT-licensen, mens koden ligger på GitHub. Migrationer beskrives ved hjælp af T-SQL.
Hvilke fordele er der:
- Understøttelse af mange databaser (MS SQL Server, PostgreSQL, MySQL).
- Da scripts skrives i T-SQL, er de ret enkle at forstå.
- Konflikter løses også ved hjælp af SQL
Men ulemperne:
- På trods af det store udvalg af understøttede DBMS'er, er Oracle ikke en del af dem
- Interagerer ikke med ORM
- At skrive scripts i T-SQL manuelt er ikke ligefrem det, vi stræbte efter
- Dokumentation og community er ikke imponerende, selvom de måske ikke er nødvendige i forbindelse med skrivning af SQL-scripts.
RoundhousE
Dette migrationsstyringsværktøj, der distribueres under Apache 2.0-licensen, fungerer ligesom det forrige på T-SQL migrationsmotoren. Ifølge rapporterne prioriterede udviklerne at løse tekniske problemer med DBMS-support frem for at skabe en komfortabel udviklingsproces.
Fordele:
- Understøtter nødvendige DBMS'er (inklusive Oracle)
Ulemper:
- Oracle (og det uddaterede Access) understøttes ikke på .NET Core, kun på .NET Full Framework
- Fungerer ikke med ORM
- Der er endnu mindre dokumentation end for det tidligere værktøj
- Igen – migrationer skrives med scripts
ThinkingHome.Migrator
Et værktøj til versionsmigration af databaseskemaer til .NET Core-platformen, distribueret under MIT-licensen. .
Fordele:
- Designet til .NET Core
- Implementeret med en forgrenet sekvens af migrationer
- Logning af migrationer er implementeret
Ulemper:
- Den sidste opdatering var for et år siden. Projektet ser ikke ud til at blive understøttet
- Oracle understøttes ikke (artiklen angiver, at det er på grund af mangel på en stabil implementation på .NET Core – men det var for et år siden)
- Mangel på automatisk generering af migrationer
Generelt fremstår projektet lovende, især hvis det udviklede sig, men vi måtte tage en beslutning her og nu.
Fluent Migrator
Det mest populære migrationsværktøj, der har en stor fanskare. Distribueres under Apache 2.0-licensen. Som angivet i beskrivelsen er det en migrationsplatform for .NET, svarende til Ruby on Rails Migrations. Ændringer i databaseskemaet beskrives i klasser på C#.
Her er der fordele:
- Understøttelse af nødvendige DBMS'er
- Understøttelse af .NET Core
- Et stort udviklet community
- Migreringskonflikter løses sekventielt – migrations oprettes med angivelse af rækkefølge for udførelse. Derudover, hvis der opstår konflikt omkring en enkelt enhed, håndteres løsning ved merging af koden på samme måde som i resten af koden.
- Der er profiler, der udføres efter en vellykket migrering. Og de kan indeholde servicefunktioner. Den seneste opdatering var for en måned siden, hvilket betyder, at projektet fortsætter med at leve.
Når det kommer til ulemper, så er der følgende:
- Mangel på automatisk generering af migrationer
- Manglende forbindelse til EF-modeller
- Ingen database-snapshot
Hvad var vores valg?
De mest intense debatter dukkede op omkring to parametre – automatisk generering af migreringer og en rimelig løsning på konflikter. Andre faktorer skræmte ikke så meget. I sidste ende besluttede teamet at bruge Fluent Migrator i det nye projekt. For løsningen af konflikter vil på længere sigt medføre mange flere fordele.
Konklusioner
Selvfølgelig findes der ikke perfekte værktøjer. Vi måtte prioritere i vores 'ønsker' for beslutningen. Men for andre teams og andre opgaver kan andre faktorer vise sig at være afgørende. Vi håber, at denne artikel vil hjælpe dig med dit valg.
Kilde: habr.com
