шаблоны миграции производственных данных в непрерывной доставке

Каковы шаблоны миграции реляционной базы данных (и схемы) в рабочей среде при непрерывной доставке?

Во многих традиционных разработках администратор базы данных создает большой сценарий миграции из множества небольших сценариев, созданных в текущем цикле выпуска. Но на компакт-диске разработчик может захотеть внести изменения в производство сейчас, а не ждать, пока они будут скомпилированы с другими скриптами.

Я знаю о rails-миграции, но мне кажется более разумным использовать необработанные скрипты sql.

Я также видел такие инструменты, как flyway для управления миграциями, но я не читал, чтобы многие люди использовали их в производственной среде. Вот почему мне интересно, каковы общие практики здесь.


postgresql continuous-deployment database flyway
person Yaron Naveh    schedule 23.07.2012    source источник

Ответы (2)


arrow_upward
11
arrow_downward

Flyway отлично подходит для непрерывной доставки/развертывания. Многие клиенты используют его во всех средах, включая производство.

Самая важная вещь для каскадной миграции БД между средами — это трехэтапный процесс:

Шаг 1

Старый код приложения работает вместе со старой БД.

Шаг 2

Новый код приложения развертывается и переносит БД при запуске. Эта миграция должна быть обратно совместимой, чтобы старый код приложения по-прежнему работал с новой БД. Это важно, потому что:

  • затем вы можете выполнять последовательные обновления, обновляя один узел за раз, пока все узлы не получат новый код приложения.
  • откат сразу к старому коду приложения, если новый сломан

Этот шаг может включать представления совместимости и триггеры для выполнения этой работы.

Шаг 3

После подтверждения того, что изменения работают, развертывается следующая версия кода приложения вместе с необходимыми миграциями БД, чтобы избавиться от любых оставшихся устаревших (из шага 1) и совместимых (из шага 2) структур.

person Axel Fontaine    schedule 23.07.2012
comment
Я понимаю, что это старый пост, но мне интересно, есть ли у вас какие-либо идеи о том, как это должно быть упаковано. Как я вижу, вы получите 4 разных пакета: 1: новый код, предназначенный для работы с новой базой данных (но также и со старой), 2: миграция базы данных, 3: новый код, исправлено, чтобы больше не поддерживать старую базу данных Часто все из этих изменений сделаны и зафиксированы в системе управления версиями, запуская сборку. Знаете ли вы какие-либо инструменты, которые могут помочь разделить на правильные пакеты для отправки в конвейер развертывания? - person Yngve B-Nilsen; 18.04.2016
comment
Новый код приложения развертывается и переносит БД при запуске. Я считаю, что миграция также представляется разумной как часть сценария развертывания. Вы видите какие-то трудности в этом? - person Shaun Luttin; 31.10.2016

arrow_upward
1
arrow_downward

Внесите изменения в свою базу данных в виде отдельных (необработанных) файлов sql, а затем используйте sqlpatch для создания сценария миграции.

Обычно у меня есть один репозиторий git только для базы данных и прикрепленная к нему среда cd. Обычно у меня есть производственная и разрабатываемая базы данных, которые автоматически переносятся, когда я нажимаю на соответствующие ветки.

Эта настройка позволяет очень легко настроить другую базу данных для функциональной ветки и поэкспериментировать с ней. Sqlpatch позаботится обо всех зависимостях в отдельных файлах sql, чтобы я мог легко объединить ветку функций в другую ветку.

person Elmer    schedule 29.04.2015
comment
Кстати, я создатель sqlpatch - person Elmer; 29.04.2015