Порівняння та вибір систем міграції даних
Модель даних у процесі розробки має властивість змінюватися, і в якийсь момент вона перестає відповідати базі даних. Звичайно ж, БД можна видалити, і тоді 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
- Вільний мігратор
А тепер трохи докладніше
Звичайно, це був перший та основний варіант для вибору. Нативний інструмент, що працює з коробки без танців з бубном. Велика кількість документації, офіційна і не дуже, простота і т.д. Проте претензії, які ставилися до класичного 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 – але це рік тому)
- Відсутня автогенерація міграцій
Загалом проект виглядає перспективним, особливо якщо розвивався б, але нам необхідно було приймати рішення тут і зараз.
Вільний мігратор
Найбільш популярний інструмент міграцій, який має велику армію шанувальників. Поширюється за ліцензією Apache 2.0. Як зазначено в описі, є платформою міграції для .NET, аналогічною Ruby on Rails Migrations. Зміни схеми БД описуються класах на C#.
Тут є плюси:
- Підтримка необхідних СУБД
- Підтримка .NET Core
- Велике розвинене ком'юніті
- Конфлікти міграцій вирішуються послідовно – у міграцій зазначається порядок виконання. Крім того, якщо виникає конфлікт навколо однієї сутності, при мерджингу коду його рішення проводиться так само, як і в іншому коді
- Існують профілі, які виконуються після успішного виконання міграції. І можуть нести в собі сервісні функції. Останнє оновлення було місяць тому, тобто проект живе
Що ж до мінусів, то тут:
- Відсутня автогенерація міграцій
- Відсутній зв'язок із моделями EF
- Немає знімків БД
Яким же був наш вибір?
Найгарячіші суперечки розгорнулися навколо двох параметрів – автогенерація міграцій та осудного вирішення конфліктів. Інші фактори лякали набагато менше. У підсумку за результатами обговорення командою було прийнято рішення використовувати в новому проекті Fluent Migrator. Бо розв'язання конфліктів у подальшій перспективі принесе набагато більше плюсів.
Висновки
Звісно, ідеальних інструментів немає. Ось і нам для вибору довелося розставити пріоритети у наших «хотелках». Однак, для інших команд та інших завдань можуть бути вирішальними інші фактори. Сподіваємося, ця стаття допоможе вам зробити вибір.
Джерело: habr.com