Как стать автором
Обновить

Комментарии 11

Чего только люди не наизобретают - лишь бы не использовать flydb/liquibase etc.

Ответ ниже.

Если кто-то будет искать ответ ниже, его там нет.

"Liquibase предназначен только для наката скриптов на БД. После первичного ознакомления не пришли к решению, как его можно совместить с другими сервисными операциями."

Ответ ниже есть, но если кто-то не сможет его там найти, то с удовольствием процитирую )

Добрый день. Спасибо за статью.

В сторону Liquibase не смотрели?

Наша итоговая цель, над которой работаем – один микросервис для обслуживания системы. Помимо прочего он включает накат скриптов на БД и деплой приложения. Причем в некоторых случаях это должно происходить синхронно.

Liquibase предназначен только для наката скриптов на БД. После первичного ознакомления не пришли к решению, как его можно совместить с другими сервисными операциями.

Поэтому решили, что в нашем случае универсальнее будет сделать свой инструмент. Тут плюс еще в том, что мы можем в любой момент собственный инструмент изменить под процесс, а не наоборот, подстраиваться под возможности стороннего продукта.

А можно как-то подробнее? Задача выглядит как супер-стандартная и решаемая Liquibase-ом. Очень хочется чтобы была раскрыта тема сравнения с Flyway и Liquibase.

P.S. Пункт "желание не использовать коробочные решения, а еще разбавить поток бизнес-задач разработкой инструмента" из дано вглядит крайне дико и наталкивает на мысли, что на анализ существующих решений не было потрачено необходимого времени.

Подробнее: полный деплой релиза для системы, состоящей из монолита + несколько новых микросервисов и БД Oracle, осуществляемый из одного инструмента, в котором определен сценарий установки всего релиза.

Запуск - в ручном режиме пользователем или по расписанию без участия сотрудника.

Накат изменений на БД зависит от изменения в приложении.

Flyway, признаемся, не смотрели.

Смотрели в сторону Liquibase, но не нашли возможности деплоя и скриптов, и модулей приложения.

Возможно, плохо смотрели :)

Однако при изучении Liquibase сразу столкнулись с тем, что нужно привлекать специалистов смежных отделов - сетевики, инфобез, админы серверов, нужно делать заказ ресурсов и т.д.

При собственной реализации зависим только сами от себя. При этом время на освоение Liquibase по нашим оценкам сопоставимо со временем на разработку.

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

Спасибо за ответ!

Смотрели в сторону Liquibase, но не нашли возможности деплоя и скриптов, и модулей приложения.

А что за модули приложения? Так-то в ликвибейз и джава код выполнять можно...

При этом время на освоение Liquibase по нашим оценкам сопоставимо со временем на разработку.

По моему опыту освоение Liquibase у человека со знанием SQL занимает максимум неделя.

Практически любой бизнес-процесс можно посадить на существующие решения. И зависеть от вендора.

Зависить от вендора опесорсного решения? Так все и так от них зависят :).

Не раскрыта тема, можно ли из репозитория поднять новую базу, хотя бы, без данных. Как DDL из скриптов по типу alter table add column попадают в "основные" DDL с create table

В репозитории мы храним скрипты по созданию объектов, но данная статья немного о другом. Тут описан процесс деплоя релизов, а не переноса и разворачивания стенда с нуля.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий