Сравнение и избор на системи за миграция на данни

Сравнение и избор на системи за миграция на данни

Моделите на данни в процеса на разработка имат свойството да се променят, и в определен момент спират да отговарят на базата данни. Разбира се, базата данни може да бъде изтрита, и тогава ORM ще създаде нова версия, която ще отговаря на модела, но такава процедура ще доведе до загуба на съществуващите данни. По този начин, функцията на системата за миграция е да синхронизира схемата с модела на данни в приложението без загуба на съществуващите данни.

В рамките на тази статия бихме искали да разгледаме различни инструменти за управление на миграциите на бази данни. Надяваме се, че този обзор ще бъде полезен за разработчиците, изправени пред подобен избор.

Задача

В нашата компания в момента тече активна разработка на следващото поколение продукт – Docs Security Suite (DSS). Сървърната част е написана на .Net Core, и като СУБД съответно се използва Entity Framework Core. При проектирането на приложението използваме подход Code First.

Доменната модел на приложението се създава от няколко разработчици едновременно – всеки от които отговаря за своята логическа част на системата.

В предходното поколение DSS като система за управление на миграциите се използваше класическия Entity Framework Migrations (EF 6). Въпреки това, към него се натрупаха някои оплаквания, главното от които бе, че в EF липсва адекватен подход за разрешаване на конфликти на версии. Този факт все още ни разочарова при поправянето на бъгове в рамките на поддръжката, затова беше взето решение да се разгледат алтернативни варианти.

В резултат на дискусията се оформиха следните изисквания към системата за управление на миграциите:

1. Подкрепа за различни СУБД. Задължително MS SQL Server, PostgreSQL, Oracle, но потенциално е възможно да се използват и други.
2. Работа с ORM. Първоначално беше предвидено използването на EF Core, но на етапа на проектиране бяхме готови да разгледаме и други ORM.
3. Автогенерация на миграции. С оглед на разработката Code First, би било добре да се избегне необходимостта „да пишем ръчно“ миграции.
4. Конфликти на версии. В условията на разпределена разработка при мерджинги EF Core може да се провали поради конфликти. Това става съществен проблем, тъй като различни части на приложението се създават от различни разработчици, затова се налага да се губи много време за всеки.
5. Развита документация и поддръжка. Тук, смятаме, че пояснения не са необходими.
6. Безплатност. Критерият е условен, тъй като готови сме да разгледаме и не много скъпи системи, или скъпи, но идеални по удобство.

В резултат на малко проучване бяха намерени и признати за желателни за разглеждане следните варианти:

1. EF Core Migrations
2. DBup
3. RoundhousE
4. ThinkingHome.Migrator
5. Fluent Migrator

А сега малко по-подробно

EntityFramework Core Migrations

Естествено, това беше първият и основен вариант за избор. Нативен инструмент, работещ от кутията без никакви усложнения. Огромно количество документация, официална и не толкова, простота и т.н. Въпреки това, оплакванията, отправени към класическия EF, са напълно актуални и за EF Core.

Така че за EF Core са определени плюсове:

• Поддръжка от Microsoft, документация, включително на български, огромно комюнисти.
• Автогенериране на миграции на основата на CodeFirst.
• В сравнение с EF 6, в EF Core вече не се съхранява моментна снимка на БД. При работа с EF Core в Code First не е необходимо да се развива базата данни.
• Тъй като започваме с Code First, има възможност да се води една миграция за всички необходими доставчици на данни.
• Что се отнася до доставчиците, поддържат се и PostgreSQL, и Oracle и т.н., дори и MS SQL Server 😊.

А също и минуси:

• Разрешаването на конфликти остана на същото ниво. Необходимо е да се изгражда последователност от миграции и да се обновяват моментните снимки на БД.
• Зависимост от моделите, на основата на които са сгенерирани миграциите.

DbUp

dbup.github.io

DbUp е библиотека на .NET, която се инсталира чрез NuGet и помага за прилагане на промените в SQL Server. Тя следи кои скриптове за промени вече са изпълнени и стартира необходимите за обновление на БД. Библиотеката произлиза от проект за опенсорс блог на ASP.NET и съществува под лицензия MIT, а кода може да бъде намерен на GitHub. Миграциите се описват с помощта на T-SQL.

Какви са плюсовете:

• Поддръжка на множество СУБД (MS SQL Server, PostgreSQL, MySQL).
• Тъй като скриптовете се пишат на T-SQL, те изглеждат доста прости.
• Конфликтите също се разрешават с помощта на SQL.

А минусите:

• При всичките поддържани СУБД, Oracle не попада в техния брой.
• Не взаимодейства с ORM.
• Писането на скриптове на T-SQL ръчно не е това, към което се стремим.
• Документацията и общността не са на високо ниво, въпреки че при написването на SQL скриптове може би не са необходими.

RoundhousE

github.com/chucknorris/roundhouse

Този инструмент за управление на миграции, разпространяван под лицензия Apache 2.0, както и предишният, работи на T-SQL миграции. Изглежда, че разработчиците са поставили акцент върху решаването на технически проблеми, свързани с поддръжката на СУБД, а не върху създаването на удобен процес за разработка.

Плюсове:

• Поддържа необходимите СУБД (включително Oracle)

Недостатъци:

• Oracle (както и неактуалният за нас Access) не се поддържа на .NET Core, само на .NET Full Framework
• Не работи с ORM
• Документацията е дори по-малко от тази на предишния инструмент
• Отново – миграциите се пишат със скриптове

ThinkingHome.Migrator

Инструмент за версииране на миграции на схемата на базата данни под платформата .NET Core, разпространяван под лицензия MIT. Разработчикът пишеше за последната версия почти преди година.

Плюсове:

• Специализиран за .NET Core
• Реализирана е разклонена последователност от миграции
• Реализирано е логиране на миграции

Недостатъци:

• Последното обновление – преди година. Изглежда проектът не се поддържа
• Не се поддържа Oracle (в статията е посочено, че е заради липсата на стабилна реализация под .NET Core – но това е било преди година)
• Липсва автоматична генерация на миграции

По принцип, проектът изглежда обещаващ, особено ако беше продължавал да се развива, но трябваше да вземем решение тук и сега.

Fluent Migrator

github.com/fluentmigrator/fluentmigrator

Най-популярният инструмент за миграции, имащ голяма армия от последователи. Разпространява се под лицензия Apache 2.0. Както е посочено в описанието, е платформа за миграции за .NET, аналогична на Ruby on Rails Migrations. Промените в схемата на БД се описват в класове на C#.

Тук има предимства:

• Поддръжка на необходимите СУБД
• Поддръжка на .NET Core
• Голямо развито общество
• Конфликтите с миграции се разрешават последователно – за миграциите се посочва реда на изпълнение. Освен това, ако възникне конфликт около един обект, решението при обединяването на кода се извършва по същия начин, както и в останалата част от кода.
• Има профили, които се изпълняват след успешно завършване на миграцията и могат да носят в себе си сервизни функции. Последното обновление беше преди месец, тоест проектът живее.

Що се отнася до недостатъците, тук:

• Липсва автоматична генерация на миграции
• Липсва връзка с моделите на EF
• Няма снимки на БД

Какъв беше нашият избор?

Най-големите спорове се развиха около два параметъра – автоматична генерация на миграции и разумно решение на конфликти. Останалите фактори плаши значително по-малко. В резултат на обсъжданията екипът реши да използва Fluent Migrator в новия проект. Защото решението на конфликтите в дългосрочен план ще донесе много повече ползи.

Изводи

Разбира се, идеални инструменти не съществуват. И за нас при избора се наложи да поставим приоритети в нашите "желания". Въпреки това, за други екипи и различни задачи могат да се окажат решаващи други фактори. Надяваме се тази статия да ви помогне при избора.

Източник: habr.com