Версионирование данных БД в рамках процесса непрерывной поставки. Часть 2 | OTUS
👋 Канал OTUS в Telegram!
Посты от приглашенных гостей из IT-тусовки, полезные статьи, подборки вакансий от партнеров ➞
Подробнее

Курсы

Программирование
Разработчик игр на Unity
-40%
Vue.js разработчик
-40%
React.js разработчик
-40%
Архитектор программного обеспечения
-40%
Архитектура и шаблоны проектирования
-40%
Разработчик C++
-40%
Разработчик Node.js
-40%
Scala-разработчик
-30%
Backend-разработка на Kotlin
-30%
Программист 1С
-30%
Symfony Framework
-30%
Разработчик на Spring Framework
-20%
Разработчик Golang
-25%
C# ASP.NET Core разработчик
-25%
iOS-разработчик. Базовый курс
-25%
VOIP инженер Базы данных AWS для разработчиков Cloud Solution Architecture Agile Project Manager в IT Супер - интенсив по паттернам проектирования Супер - интенсив по Kubernetes
Специализации Курсы в разработке Подготовительные курсы
+7 499 938-92-02

Версионирование данных БД в рамках процесса непрерывной поставки. Часть 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 иногда может быть более затратной, нежели выкатка исправления (привнесение небольших и частых изменений). Есть вопрос? Пишите в комментариях!

Не пропустите новые полезные статьи!

Спасибо за подписку!

Мы отправили вам письмо для подтверждения вашего email.
С уважением, OTUS!

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