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

Курсы

Программирование
iOS Developer. Basic
-23%
Python Developer. Professional
-13%
Golang Developer. Professional
-17%
Python Developer. Basic
-16%
iOS Developer. Professional
-13%
C# ASP.NET Core разработчик
-18%
Unity Game Developer. Professional
-11%
React.js Developer
-12%
Android Developer. Professional
-7%
Software Architect
-12%
C++ Developer. Professional
-8%
Разработчик C#
-8%
Backend-разработчик на PHP
-8%
Архитектура и шаблоны проектирования
-12%
Программист С Разработчик на Spring Framework MS SQL Server Developer AWS для разработчиков Cloud Solution Architecture Разработчик голосовых ассистентов и чат-ботов Vue.js разработчик VOIP инженер Нереляционные базы данных Супер - интенсив по паттернам проектирования Супер-практикум по использованию и настройке GIT IoT-разработчик Advanced Fullstack JavaScript developer Супер-интенсив Azure
Инфраструктура
Мониторинг и логирование: Zabbix, Prometheus, ELK
-17%
DevOps практики и инструменты
-18%
Архитектор сетей
-21%
Инфраструктурная платформа на основе Kubernetes
-22%
Супер-интенсив «IaC Ansible»
-16%
Супер-интенсив по управлению миграциями (DBVC)
-16%
Administrator Linux. Professional
-5%
Administrator Linux.Basic
-10%
Супер-интенсив «ELK»
-10%
Базы данных Сетевой инженер AWS для разработчиков Cloud Solution Architecture Разработчик голосовых ассистентов и чат-ботов Внедрение и работа в DevSecOps Супер-практикум по работе с протоколом BGP Супер - интенсив по паттернам проектирования Супер - интенсив по 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 комментариев
Для комментирования необходимо авторизоваться