Параўнанне і выбар сістэм міграцыі даных
Мадэль дадзеных у працэсе распрацоўкі мае ўласцівасць змяняцца, і ў нейкі момант яна перастае адпавядаць базе дадзеных. Вядома ж, БД можна выдаліць, і тады ORM створыць новую версію, якая будзе адпавядаць мадэлі, але такая працэдура прывядзе да страты наяўных дадзеных. Такім чынам, функцыя сістэмы міграцыі зводзіцца да таго, каб у выніку змены схемы сінхранізаваць яе з мадэллю дадзеных у дадатку без страты наяўных дадзеных.
У рамках гэтага артыкула нам хацелася б разгледзець розныя інструменты для кіравання міграцыямі баз даных. Спадзяемся, гэты агляд будзе карысны для распрацоўшчыкаў, якія сутыкнуліся з падобным выбарам.
Задача
У нашай кампаніі цяпер вядзецца актыўная распрацоўка наступнага пакалення прадукта - Docs Security Suite (DSS). Серверная частка пішацца на. Net Core, і ў якасці СКБД адпаведна выкарыстоўваецца Entity Framework Core. Пры праектаванні прыкладання мы выкарыстоўваем падыход Code First.
Даменную мадэль прыкладання ствараюць некалькі распрацоўшчыкаў адначасова - кожны адказвае за сваю лагічную частку сістэмы.
У папярэднім пакаленні DSS у якасці сістэмы кіравання міграцыямі выкарыстоўваўся класічны Entity Framework Migrations (EF 6). Аднак, да яго назапасіліся некаторыя прэтэнзіі, галоўная з якіх заключалася ў тым, што ў EF адсутнічае разумны падыход да вырашэння канфліктаў версій. Гэты факт да гэтага часу нас засмучае пры багфіксінгу ў рамках падтрымкі, таму было прынята рашэнне разгледзець альтэрнатыўныя варыянты.
У выніку абмеркавання сфармаваліся наступныя патрабаванні да сістэмы кіравання міграцыямі:
- Падтрымка розных СКБД. Абавязкова MS SQL Server, PostgreSQL, Oracle, але патэнцыйна магчымае выкарыстанне і іншых
- Праца з ORM. Першапачаткова меркавалася выкарыстанне EF Core, аднак на этапе праектавання былі гатовы разгледзець і іншыя ORM.
- Аўтагенерацыя міграцый. З улікам распрацоўкі Code First неабходнасці "распісваць ручкамі" міграцыі хацелася б пазбегнуць
- Канфлікты версій. Ва ўмовах размеркаванай распрацоўкі пры мерджынгу EF Core можа валіцца на канфліктах. Гэта становіцца істотнай праблемай, паколькі розныя часткі прыкладання ствараюцца рознымі распрацоўшчыкамі, таму даводзіцца марнаваць вялікую колькасць часу на кожны
- Развітая дакументацыя і падтрымка. Тут, нам здаецца, тлумачэнні не патрэбны
- Бясплатнасць. Крытэрый умоўны, паколькі не вельмі дарагія сістэмы ці дарагія, але ідэальныя ў выгодзе, мы таксама гатовы былі разгледзець.
У выніку невялікага даследавання былі знойдзены і прызнаны пажаданымі для разгляду наступныя варыянты:
- EF Core Migrations
- DBup
- RoundhousE
- ThinkingHome.Migrator
- Fluent Migrator
А зараз крыху падрабязней
Натуральна, гэта быў першы і асноўны варыянт для выбара. Натыўная прылада, які працуе са скрынкі без якіх-небудзь скокаў з бубнам. Вялікая колькасць дакументацыі, афіцыйнай і не вельмі, прастата і т.д. Аднак прэтэнзіі, якія прад'яўляліся да класічнага EF, суцэль актуальныя і для EF Core.
Такім чынам для EF Core выдзелены плюсы:
- Падтрымка Microsoft, дакументацыя, у тым ліку на рускай, велізарнае кам'юніці
- Аўтагенерацыя міграцый на аснове CodeFirst
- У параўнанні з EF 6 у EF Core зараз не захоўваецца здымак БД. Пры працы з EF Core у Code First зараз не абавязкова разгортваць базу дадзеных
- Паколькі скачам ад Code First - ёсць магчымасць весці адну міграцыю на ўсе патрабаваныя правайдэры доступу да дадзеных
- Наконт правайдэраў – падтрымліваецца і PostgreSQL, і Oracle, і г.д., і да т.п., і нават – MS SQL Server
А таксама мінусы:
- Дазвол канфліктаў застаўся на тым жа ўзроўні. Неабходна выбудоўваць паслядоўнасць міграцый і абнаўляць здымкі БД
- Залежнасць ад мадэляў, на аснове якіх згенераваны міграцыі
DbUp
DbUp - гэта бібліятэка на .NET, якая ўсталёўваецца NuGet'ам і дапамагае накатваць змены на SQL Server. Яна адсочвае, якія скрыпты змен ужо выкананы, і запускае тыя, якія неабходныя для абнаўлення БД. Бібліятэка вырасла з праекту апенсорснага рухавічка блогаў на ASP.NET і існуе пад ліцэнзіяй MIT, а код ляжыць на GitHub'е. Міграцыі апісваюцца з дапамогай T-SQL.
Якія тут плюсы:
- Падтрымка вялікай колькасці СКБД (MS SQL Server, PstgreSQL, MySQL)
- Паколькі скрыпты пішуцца на T-SQL, выглядаюць яны даволі проста
- Канфлікты таксама вырашаюцца з дапамогай SQL
А мінусы:
- Пры ўсёй разнастайнасці падтрымоўваных СКБД, Oracle у іх лік не ўваходзіць
- Не ўзаемадзейнічае з ORM
- Напісанне скрыптоў на T-SQL ручкамі не тое, да чаго мы імкнуліся
- Дакументацыя і кам'юніці так сабе, хоць ва ўмовах напісання SQL-скрыптоў яны, магчыма, і не патрэбныя.
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
Найбольш папулярны інструмент міграцый, які мае вялікае войска прыхільнікаў. Распаўсюджваецца пад ліцэнзіяй Apache 2.0. Як паказана ў апісанні, з'яўляецца платформай міграцыі для. NET, аналагічная Ruby on Rails Migrations. Змены схемы БД апісваюцца ў класах на C #.
Тут ёсць плюсы:
- Падтрымка неабходных СКБД
- Падтрымка. NET Core
- Вялікае развітае кам'юніці
- Канфлікты міграцый вырашаюцца паслядоўна - у міграцый паказваецца парадак выканання. Акрамя таго, калі ўзнікае канфлікт вакол адной сутнасці, пры мерджынгу кода яго рашэнне вырабляецца гэтак жа, як і ў астатнім кодзе
- Ёсць профілі, якія выконваюцца пасля паспяховага выканання міграцыі. І могуць несці ў сабе сэрвісныя функцыіАпошняе абнаўленне было месяц таму, гэта значыць праект жыве
Што ж да мінусаў, то тут:
- Адсутнічае аўтагенерацыя міграцый
- Адсутнічае сувязь з мадэлямі EF
- Няма здымкаў БД
Які ж быў наш выбар?
Самыя гарачыя спрэчкі разгарнуліся вакол двух параметраў - аўтагенерацыя міграцый і разумнага рашэння канфліктаў. Іншыя фактары палохалі значна менш. У выніку, па выніках абмеркавання камандай было прынятае рашэнне выкарыстоўваць у новым праекце Fluent Migrator. Бо вырашэнне канфліктаў у далейшай перспектыве прынясе значна большую колькасць плюсаў.
Высновы
Вядома, ідэальных прылад не бывае. Вось і нам для выбару прыйшлося расставіць прыярытэты ў нашых "хацялках". Аднак, для іншых каманд і іншых задач могуць аказацца вырашальнымі іншыя фактары. Спадзяемся, дадзены артыкул дапаможа вам зрабіць выбар.
Крыніца: habr.com