Как оптимально переносить состояние таблиц и объектов PL/SQL из БД в Git?

Question

[Филипп Гинкель]

Наши клиенты работают с большим продуктом, у которого основная конфигурация, реализующая различные бизнес-процессы, хранится в виде PL/SQL и записей в таблицах. Также реализован процесс хранения и установки этой конфигурации на различные стенды (Prod, Preprod) заказчика.

Стек: Oracle, GitLab, Liquibase, Jenkins

Схема такая:

1. Заказчик вносит изменения в тестовой среде (правятся/вносятся записи в БД, пакеты, процедуры)
   
2. После успешного тестирования изменения вручную выгружаются и добавляются в CSV (для таблиц) или в .sql-файлы (для PL/SQL) в наш Git-репозиторий. Создается Merge Request
   
3. Мы вручную запускаем Jenkins-сборку, которая на локальном стенде запускает миграцию Liquibase по изменённым в MR объектам
   
4. Изменения применяются
   
   или
   
   
5. Возникают ошибки, которые правятся либо силами заказчика, либо нашими
   
6. С определённой периодичностью формируется релизная сборка, включающая все изменения заказчика
   
7. Заказчик устанавливает её на своих стендах через Ansible + Liquibase
   

Основная боль заключается в п.2, который влечёт за собой п.5:

1. После конфигурирования заказчик вынужден тратить время на корректный перенос информации в .csv и .sql
   
2. Merge-конфликты, потому что ветка заказчика не основана на актуальной версии ветки master
   
3. Синтаксические ошибки при переносе данных в .csv (забыли delimiter, исправили не то значение/не ту строку)
   
4. Забыли перенести все изменения (в результате при сборке возникают ошибки вроде violates foreign key constraint: Key (customer_id)=(123) is not present in table "customers", либо в Git зафиксировано только тело пакета без спецификации)
   
5. В changeset к таблице указан primary key, который не обеспечивает уникальность строки (например, в таблице есть constraint на поле number_history, но его нет в changeset, и вместо вставки новой строки происходит update)
   

Я заинтересован в оптимизации этого процесса и максимальном упрощении переноса выполненных изменений из БД в Git.
Какие есть best practices?
Какие инструменты для этого используются?

Answer 1

[rPman]

В одном старом проекте, необходимые структуры сохранялись в машиночитаемом виде (пусть будет json), сохраняется целиком вся текущая структура. Можно облегчить жизнь git и тем кто будет смотреть глазами дифы для написания комментариев к коммиту, если сохранять его с построчным форматированием на объект/свойство (построчно для БД).

Пишется утилита, которая доводит текущее состояние базы данных до указанной структуры, а именно удаляет удаленное, изменяет - измененное и добавляет новое (особо уделить время для реализации что бы изменения были именно изменения, а не удалил + добавил, только так корректно связи в базе останутся, для этого либо озаботиться идентификаторами, если структуру правит кто то один, либо как то договариваться о пометках между релизами в доп полях) и пусть она запускается после обновлений у клиента.

Comments

[Филипп Гинкель]

Добрый день, мне кажется или то что вы описали и есть наш текущий процесс с liquibase?

[rPman]

Филипп Гинкель, точно нет, я с этим ковырялся лет 10 назад если уже не 15, я уже и не помню всего, такие вещи быстрее придумать заново чем вспомнить и найти

Answer 2

[Игорь Махов]

Возможно, вам пригодится что-то из этого: https://github.com/bytebase/bytebase, https://github.com/dolthub/dolt

Answer 3

[Сергей Кузнецов]

Можно попробовать подойти к задаче через автоматическую генерацию миграций из базы, чтобы не переносить данные вручную в CSV и SQL.

Вот несколько подходов, которые могут помочь:

1. Liquibase diff
   
   Liquibase умеет сравнивать текущее состояние базы с эталонным snapshot или changelog (команды liquibase diff, generateChangeLog). Это может автоматически сгенерировать changesets. Не всегда идеально, особенно для данных, но может служить хорошей стартовой точкой.
   
   
2. Скрипт дампа и автоформатирования
   
   Написать утилиту, которая:
   
   • выгружает актуальные записи (по дате или через служебную метку),
     
   • форматирует результат построчно (для удобных диффов в Git),
     
   • сохраняет в SQL или CSV с нужным форматированием,
     
   • проверяет ошибки: зависимости, ключи, синтаксис и т. п.
     
   
   
3. Служебное поле change_id
   
   Добавление такого поля в ключевые таблицы упростит группировку и экспорт связанных изменений. Это также упростит отладку и проверку связей.
   
   
4. Проверки перед мержем
   
   Автоматический pre-merge скрипт может:
   
   • проверять, что ветка актуальна относительно master,
     
   • валидировать синтаксис SQL и CSV,
     
   • выявлять ошибки в зависимостях (foreign keys, отсутствие spec при наличии body и т. п.),
     
   • проверять потенциальные конфликты по ключам в changesets.
     
   
   
5. Dolt и Bytebase
   
   Как уже писали выше, эти проекты позволяют рассматривать базу как репозиторий Git. Подход интересный, но требует серьёзной перестройки процессов. Внедрение возможно, если проект активно развивается и готов к архитектурным изменениям.
   

Если кратко: можно улучшить текущую схему с помощью автоматизации и валидации, либо двигаться в сторону Git-ориентированных решений, где изменения фиксируются на уровне базы, а не вручную.