Как лучше всего перенести состояние таблиц и объектов PL/SQL из базы данных в систему управления версиями GIT?

Здравствуйте! <br/> <br/> Наши клиенты работают с крупным продуктом, в котором основная конфигурация, реализующая различные бизнес-процессы, хранится в формате PL/SQL и в таблицах. Кроме того, для хранения и установки этой конфигурации на разные стенды (Prod, Preprod) заказчика уже реализован процесс. <br/> <br/> <i>Стек: Oracle, Gitlab, Liquibase, Jenkins</i> <br/> В этом контексте, основная проблема заключается в пункте 2, что в свою очередь вызывает затруднения, описанные в пункте 5: <br/> <br/> Я хотел бы узнать, как оптимизировать данный процесс и максимально упростить перенос изменений из базы данных в git. Какие являются лучшие практики в этой области? Какие инструменты могут быть для этого полезны?
  • 19 марта 2025 г. 19:34
Ответы на вопрос 2
Перенос состояния таблиц и объектов PL/SQL из базы данных в систему управления версиями, такую как GIT, может быть сложной задачей, особенно в контексте крупного проекта с динамически изменяющейся конфигурацией. Вот несколько рекомендаций и лучших практик по оптимизации этого процесса:

### 1. Использование Liquibase
Liquibase — это инструмент для управления изменениями в базе данных, который позволяет отслеживать, управлять и применять миграции. Вы можете использовать его для создания изменений в виде скриптов (change sets), которые можно хранить в вашей системе контроля версий.

#### Рекомендации:
- Создайте файл `changelog.xml` или `changelog.yml`, в котором будут описаны все изменения, такие как создание/изменение таблиц, хранимых процедур и триггеров.
- Используйте команду `liquibase diff` для создания скриптов миграции на основе текущего состояния базы данных и состояния в Git.

### 2. Генерация миграций
Чтобы упростить процесс переноса изменений, автоматизируйте генерацию скриптов миграции. Вы можете использовать PL/SQL утилиты или сторонние инструменты, чтобы создать SQL-скрипты, которые потом можно будет добавлять в GIT.

#### Примеры утилит:
- **SQL Developer**: позвольте экспортировать схему в виде SQL-скрипта.
- **TOAD**: имеет функции для сравнения схем и генерации DDL-скриптов.

### 3. Структурированное хранение скриптов
Храните скрипты в GIT в организованном виде, например:
```
/db
  /migrations
    /V1__initial_setup.sql
    /V2__add_new_table.sql
  /rollback
    /V1__rollback.sql
```
Такой подход позволит вам легко управлять версиями и отслеживать изменения.

### 4. Автоматизация с Jenkins
Используйте Jenkins для автоматизации процесса развертывания миграций в разные окружения. Создайте Jenkins Pipeline, который будет выполнять скрипты миграции при каждом изменении в репозитории.

### 5. Документация и версионирование
Документируйте все изменения, которые вы вносите в базу данных. Это может быть полезно как для вас, так и для других членов команды, чтобы понимать, какие изменения были сделаны и почему.

### 6. Тестирование миграций
Прежде чем применять миграции в продуктивной среде, протестируйте их на предварительном стенде. Это можно сделать через Jenkins, управляя конфигурациями для разных окружений.

### 7. Использование git hooks
Настройте git hooks для автоматизации некоторых процессов, таких как проверка синтаксиса PL/SQL перед коммитом или автоматическое выполнение тестов миграций.

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

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