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

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

Transcript

1. Миграции БД: подходы и инструменты Мария Щекочихина Архитектор приложений
2. Аннотация Рано или поздно перед разработчиком встают вопросы, как синхронизировать стенды с базами данных между собой и как встраивать обновление баз в процесс CI/CD. В докладе будут рассмотрены два подхода к миграции баз данных, рыночные инструменты для решения таких задач в стеке технологий Microsoft, наш опыт смены подхода и сложности, с которыми мы столкнулись. 2
3. Подходы к миграции БД  State-based database migration / State-driven database delivery  Change script-based database migration / Migration-driven database delivery 3
4. State-based database migration 4 Эталонная БД Скрипты эталона CREATE TABLE... Целевая БД Database Project (dacpac) Compare Tool Upgrade Scripts Deploy/Execute  Сравнение состояний БД  Приведению БД к эталонному состоянию
5. Change script-based database migration 5 БД Ver 1 БД Ver 2 БД Ver 3 БД Ver N Change Scripts 1 Change Scripts 2 Change Scripts N Последовательный накат скриптов изменений на БД
6. Сравнение подходов 6 State-based migration Change script-based migration  Есть эталонное состояние БД  Состояние хранится в терминах create  В любой момент времени любая БД может быть приведена к эталону  Скрипт создается только на дельту между эталоном и БД  Полуавтоматическая генерация скриптов alter  Разработчики могут работать в любом редакторе SQL или в дизайнере  Сложности со встройкой в процесс миграции скриптов на изменения данных (ручная работа)  Нет эталонного состояния БД  Есть начальное состояние БД и набор скриптов изменений  Низкий порог входа в подход  Со временем количество скриптов накапливается, усложняются зависимости между ними  Увеличение времени наката патчей из-за увеличения количества скриптов  Сложности с мерджем скриптов, когда два разработчика вносили изменения в один и тот же объект  Полностью скриптовый подход  Скрипты пишутся на внутреннем языке инструмента (в большинстве)  Так же ручные скрипты для изменения данных  Требуется установка своих артефактов на БД (для отслеживания версионности)
7. Инструменты 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
8. Database Source Control  Позволяет автоматически собирать и хранить в выбранном репозитории (svn, git и др.) исходные коды БД  Нужен для организации работы с БД как с обычным кодом: branch, merge и т. д.  Отслеживает изменения, сравнивает версии средствами репозитория State-based migration: хранится эталонное состояние Change script-based migration: начальное состояние и инкремент 8
9. Database Source Control: примеры 9
10. Сравнение инструментов 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
11. Проблемы подхода Change script-based migration  Много ручной работы по сбору и подготовке патчей → повышается трудоемкость рутинных операций  Необходимость изучения языка написания скриптов  Проблемы стабилизации  Неаккуратность разработчиков 11
12. Примеры: Liquibase 12
13. А как у нас? 13
14. Сценарии отдела C#  Загрузка и установка патча на серверы (серверов мало: в каждом продукте 4–5 серверов, включая боевой)  В патчах используются параметры (например, PWD_OF_RMS). Патчер автоматически заменяет эти параметры на нужные значения (на разных серверах они могут быть разными)  Загрузка и установка патча в контуре CUSTIS автоматизированы (делаются из командной строки или по нажатию на кнопку в TeamCity)  Проверка невалидных объектов после установки патча/фикса  Рассылка писем об успешном завершении установки патча  Отслеживание времени, которое заняла установка патча 14
15. CUSTIS Patcher  Change script-based migration  Наследует все проблемы подхода  Содержит часть от инструментов класса управления инсталляциями БД 15
16. Сложности смены подхода к миграции  Перестройка текущих процессов работы  Инерция команды, управления, процессов  Покупка инструментов 16
17. CI/CD  Управление проносами за счет отдельных инструментов, например TeamCity  Пронос БД вместе с основным приложением  Вариант запуска через консоль 17
18. Рекомендуемые процессы 18
19. Какие шаги почти никто не делает в подходе change script-based? 19
20. Примеры: RedGate Schema Compare 20
21. Примеры: RedGate Schema Compare 21
22. Примеры: Database Project 22
23. Примеры: Database Project 23
24. Выводы  Инструментов много  Выбирайте их, исходя из своих потребностей  Смотрите на команду, их компетенции, готовность изучать новый инструмент (время на него) 24
25. Спасибо за внимание! Мария Щекочихина mschekochikhina@custis.ru 25
26. Вопросы  Как встроить миграции в процесс CI/CD и какие шаги почти никто не делает?  Как обеспечить идентичность схем баз данных, созданных from scratch и инкрементными обновлениями?  Как использовать реальные данные на тестовом стенде, но не засветить конфиденциальную информацию перед новыми заказчиками или аутсорсерами? 26