модели на миграция на производствени данни при непрекъсната доставка

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

В много традиционни разработки DBA организира голям скрипт за миграция от множеството по-малки скриптове, създадени в текущия цикъл на издаване. Но в CD разработчикът може да иска да натисне промяната сега в производството, а не да чака да ги компилира с други скриптове.

Знам за rails-migration, но за мен изглежда по-разумно да се използват необработени sql скриптове.

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


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

Отговори (2)


arrow_upward
11
arrow_downward

Flyway работи чудесно за непрекъсната доставка/разгръщане. Много клиенти го използват във всички среди, включително производство.

Единственото най-важно нещо за каскадни миграции на DB между среди е да има процес от 3 стъпки:

Стъпка 1

Старият код на приложението работи заедно със старата база данни.

Стъпка 2

Новият код на приложението се внедрява и мигрира DB при стартиране. Тази миграция трябва да бъде обратно съвместима, така че старият код на приложението да работи с новата база данни. Това е от съществено значение, защото:

  • след това можете да правите непрекъснати надстройки, надграждайки един възел наведнъж, докато всички възли имат новия код на приложението
  • незабавно връщане към стария код на приложението, ако новият е повреден

Тази стъпка може да включва изгледи за съвместимост и тригери за извършване на работата.

Стъпка 3

След като е доказано, че промените работят, следващата версия на кода на приложението се внедрява заедно с необходимите миграции на DB, за да се отхвърлят всички останали остарели (от стъпка 1) и структури за съвместимост (от стъпка 2).

person Axel Fontaine    schedule 23.07.2012
comment
Осъзнавам, че това е стара публикация, но се чудя дали имате някакви идеи за това как трябва да бъде опаковано. Както виждам, в крайна сметка ще имате 4 различни пакета: 1: Нов код, осигурен за работа с нова база данни (но също и стара), 2: Миграция на база данни, 3: Нов код, фиксиран, за да не поддържа старата база данни Често всички от тези промени са направени и ангажирани с контрол на източника, задействайки компилация.. Знаете ли за някакви инструменти, които могат да помогнат за разделянето на правилни пакети за изпращане към конвейера за внедряване? - person Yngve B-Nilsen; 18.04.2016
comment
Новият код на приложението се внедрява и мигрира DB при стартиране. Мисля, че също така изглежда разумно миграцията да се изпълнява като част от скрипта за внедряване. Виждате ли някаква трудност в това? - 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