Несколько дней новогоднего волшебства:
Успейте начать обучение в 2018-ом году со скидкой до 30%!
Выбрать курс

Версионирование данных БД в рамках процесса непрерывной поставки. Часть 2

DevOpsDeep11.05_Site.png В первой части мы обсудили проблемы, которые решаются с помощью IaС-инструментов. Определив задачи и результаты их решения, в этой заметке я хотел бы рассказать о том, как можно управлять миграциями с помощью liquibase. Есть два способа: 1. Описывать и запускать их при помощи CLI liquibase в процессе деплоя; 2. Описывать миграции вместе с кодом приложений и запускать их применение во время запуска приложений. В первом случае, удобство заключается в том, что все миграции и сама утилита могут поставляться в виде версионированного артефакта. Мне кажется, он подойдёт для монолитных приложений. Второй же даёт простор внесения изменений в случае, когда у проекта много сервисов, которые часто и мало меняются. Стоит учитывать, что способ описания миграций, которые лежат рядом с кодом приложения, также ограничены возможностями интеграции инструмента с кодом проекта. В случае с liquibase интеграция выполнена с Java-кодом с поддержкой интеграции в ряд фреймворков.

Рассмотрим пример описания миграций в виде кода

Для описания миграций liquibase предоставляет возможность описывать их в виде xml- или yml-файлов. Две версии изменений в виде yml будут выглядеть так:
databaseChangeLog:
  - preConditions:
    - runningAs:
        username: migrations

- changeSet: id: 1 author: holyowly changes: - createTable: tableName: club columns: - column: name: id type: int autoIncrement: true constraints: primaryKey: true nullable: false - column: name: firstname type: varchar(50) - column: name: lastname type: varchar(50) constraints: nullable: false - column: name: club_status type: varchar(8)

- changeSet: id: 2 author: holyowly changes: - addColumn: tableName: club columns: - column: name: club_status type: varchar(32)

Пример демонстрирует описание двух миграций в виде yml-кода: в первой версии создаётся таблица club с тремя колонками (firstname, lastname, club_status); вторая миграция изменяет тип для club_status, расширяя возможности описания club_status по количеству символов. Такая ситуация может возникнуть, когда сперва создался функционал требующий наличия таблицы club у приложения, а через некоторое время функционал, затрагивающий колонку club_status, потребовал возможности хранить больше текста в ней. Во время выполнения вышеописанного сценария liquibase считает yml-код и попытается его применить. А узнать о том, нужно ли применять миграции, их статус и очередность выполнения liquibase сможет при помощи мета-таблицы. За счёт неё же достигается идемпотентность.

И напоследок о роллбеках (откаты миграций)

liquibase и flyway поддерживают данный функционал. Однако стоит учитывать, что поддержка rollback иногда может быть более затратной, нежели выкатка исправления (привнесение небольших и частых изменений). Есть вопрос? Пишите в комментариях!

Автор
0 комментариев
Для комментирования необходимо авторизоваться