Добавочные снимки Liquibase - PullRequest
Новая
       23

Добавочные снимки Liquibase

0 голосов
/ 27 мая 2020

У нас есть довольно интересный вариант использования, когда мы используем Liquibase для развертывания базы данных для нашего приложения, но на самом деле мы не контролируем базу данных. Это означает, что нам нужно добавлять много дополнительных logi c каждый раз, когда мы запускаем Liquibase, чтобы избежать каких-либо ошибок во время фактического запуска. Один из способов, которым мы это сделали, состоит в том, что мы генерируем моментальные снимки того, как должна выглядеть БД для каждой версии нашего продукта, а затем сравниваем этот моментальный снимок с работающей БД, чтобы узнать, находится ли она в совместимом состоянии. Файлы моментальных снимков для нашей полной базы данных - это не giganti c, но если нам нужно иметь полный файл для каждого возможного выпуска, это может привести к тому, что наш программный пакет в будущем станет большим мертвым грузом.

Мы Мы рассмотрели использование команды Linux patch для создания файлов смещения, поскольку разница между этими файлами обычно будет очень небольшой (например, изменение 1 столбца и т. д. c.), но проблемы связаны с сгенерированными идентификаторами в моментальном снимке, которые не согласовано между прогонами: 

    "snapshotId": "aefa109",
    "table": "liquibase.structure.core.Table#aefa103"

Есть ли способ заставить идентификаторы быть последовательными или решить эту проблему другим способом?

Спасибо!

1 Ответ

0 голосов
/ 28 мая 2020

Возможно, нам следует изменить то, как мы думаем о развертывании PROD. Когда я прочитал:

Это означает, что нам нужно добавлять много дополнительных logi c каждый раз, когда мы запускаем Liquibase, чтобы избежать каких-либо ошибок во время фактического запуска.

Это своего рода антипаттерн в мире Liquibase. Как правило, Liquibase используется в конвейере CI / CD, а развертывание SQL выполняется в «более низких средах» для практики развертывания PROD (которое многие не контролируют, поэтому ваша ситуация является распространенной).

Когда мы пытаемся учесть возможные ошибки во время развертывания PROD, я чувствую, что мы уже находимся в плохом положении с нашей автоматизацией развертывания. Мы должны были тестировать развертывание в более низких средах, которые выглядят как PROD.

Например, ваш конвейер для вашей БД может выглядеть так:

  • DEV-> QA-> PROD
  • Создать SQL для развертывания в журнале изменений
  • DEV и QA с восстановлением из текущего состояния PROD (возможно, без данных строки)
  • У вас будет весь контроль в DEV (Дикий Запад)
  • Меньший контроль QA (обычно только QA)
  • Итерируйте, пока у вас не будет ошибок в вашем DEV & QA env
  • Развернуть на PROD

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

Надеюсь, что это поможет,

Ронак

...