Теги: liquibase, flyway, базы данных, xml, версионирование данных, iaс-инструменты, rollback, infrastructure as code, yml-код, firstname, cli liquibase, миграции, процесс непрерывной поставки, lastname, club_status
В первой части мы обсудили проблемы, которые решаются с помощью 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 иногда может быть более затратной, нежели выкатка исправления (привнесение небольших и частых изменений).
Есть вопрос? Пишите в комментариях!
