Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Миграции БД: подходы и инструменты

CUSTIS
November 01, 2018

Миграции БД: подходы и инструменты

Выступление Марии Щекочихиной, нашего архитектора приложений, на CUSTIS Meetup (Москва, 1 ноября 2018).

CUSTIS

November 01, 2018
Tweet

More Decks by CUSTIS

Other Decks in Programming

Transcript

  1. Аннотация Рано или поздно перед разработчиком встают вопросы, как синхронизировать

    стенды с базами данных между собой и как встраивать обновление баз в процесс CI/CD. В докладе будут рассмотрены два подхода к миграции баз данных, рыночные инструменты для решения таких задач в стеке технологий Microsoft, наш опыт смены подхода и сложности, с которыми мы столкнулись. 2
  2. Подходы к миграции БД  State-based database migration / State-driven

    database delivery  Change script-based database migration / Migration-driven database delivery 3
  3. State-based database migration 4 Эталонная БД Скрипты эталона CREATE TABLE...

    Целевая БД Database Project (dacpac) Compare Tool Upgrade Scripts Deploy/Execute  Сравнение состояний БД  Приведению БД к эталонному состоянию
  4. Change script-based database migration 5 БД Ver 1 БД Ver

    2 БД Ver 3 БД Ver N Change Scripts 1 Change Scripts 2 Change Scripts N Последовательный накат скриптов изменений на БД
  5. Сравнение подходов 6 State-based migration Change script-based migration  Есть

    эталонное состояние БД  Состояние хранится в терминах create  В любой момент времени любая БД может быть приведена к эталону  Скрипт создается только на дельту между эталоном и БД  Полуавтоматическая генерация скриптов alter  Разработчики могут работать в любом редакторе SQL или в дизайнере  Сложности со встройкой в процесс миграции скриптов на изменения данных (ручная работа)  Нет эталонного состояния БД  Есть начальное состояние БД и набор скриптов изменений  Низкий порог входа в подход  Со временем количество скриптов накапливается, усложняются зависимости между ними  Увеличение времени наката патчей из-за увеличения количества скриптов  Сложности с мерджем скриптов, когда два разработчика вносили изменения в один и тот же объект  Полностью скриптовый подход  Скрипты пишутся на внутреннем языке инструмента (в большинстве)  Так же ручные скрипты для изменения данных  Требуется установка своих артефактов на БД (для отслеживания версионности)
  6. Инструменты 7 State-based migration Change script-based migration  RedGate: Source

    Control, Schema Compare, Data Compare  Microsoft SSDT (Database projects)  Visual Studio Schema Comparison, Data Comparison  Devart Schema Compare, Data Compare  Liquibase/Datical  Flywaydb  CUSTIS Patcher
  7. Database Source Control  Позволяет автоматически собирать и хранить в

    выбранном репозитории (svn, git и др.) исходные коды БД  Нужен для организации работы с БД как с обычным кодом: branch, merge и т. д.  Отслеживает изменения, сравнивает версии средствами репозитория State-based migration: хранится эталонное состояние Change script-based migration: начальное состояние и инкремент 8
  8. Сравнение инструментов 10 RedGate Liquibase/Datical Microsoft SQL Schema Compare SQL

    Data Compare Datasource Control Liquibase Datical Visual Studio Database projects (.dacpac) Open source Нет Да Нет Подход State-based Change script-based State-based Скрипты SQL Основной и рекомендуемый XML, есть поддержка SQL-скриптов SQL Артефакты работы в БД Нет Да Необязательно Интерфейс GUI Console GUI Поддерживаемые БД MS SQL Server, Oracle Database MS SQL Server, PostgreSQL, Oracle Database и другие MS SQL Server
  9. Проблемы подхода Change script-based migration  Много ручной работы по

    сбору и подготовке патчей → повышается трудоемкость рутинных операций  Необходимость изучения языка написания скриптов  Проблемы стабилизации  Неаккуратность разработчиков 11
  10. Сценарии отдела C#  Загрузка и установка патча на серверы

    (серверов мало: в каждом продукте 4–5 серверов, включая боевой)  В патчах используются параметры (например, PWD_OF_RMS). Патчер автоматически заменяет эти параметры на нужные значения (на разных серверах они могут быть разными)  Загрузка и установка патча в контуре CUSTIS автоматизированы (делаются из командной строки или по нажатию на кнопку в TeamCity)  Проверка невалидных объектов после установки патча/фикса  Рассылка писем об успешном завершении установки патча  Отслеживание времени, которое заняла установка патча 14
  11. CUSTIS Patcher  Change script-based migration  Наследует все проблемы

    подхода  Содержит часть от инструментов класса управления инсталляциями БД 15
  12. Сложности смены подхода к миграции  Перестройка текущих процессов работы

     Инерция команды, управления, процессов  Покупка инструментов 16
  13. CI/CD  Управление проносами за счет отдельных инструментов, например TeamCity

     Пронос БД вместе с основным приложением  Вариант запуска через консоль 17
  14. Выводы  Инструментов много  Выбирайте их, исходя из своих

    потребностей  Смотрите на команду, их компетенции, готовность изучать новый инструмент (время на него) 24
  15. Вопросы  Как встроить миграции в процесс CI/CD и какие

    шаги почти никто не делает?  Как обеспечить идентичность схем баз данных, созданных from scratch и инкрементными обновлениями?  Как использовать реальные данные на тестовом стенде, но не засветить конфиденциальную информацию перед новыми заказчиками или аутсорсерами? 26