lleming,

1. использовать что-то менее топорное, а не flyway
2. ревьювить
3. гонять скрипты на специально подготовленной базе (нужно этим специально заниматься, да)
4. забыть про существование серебряных пуль - деплой в прод всегда начинается с бэкапа

Petro123Если нет в штате ДБА/уборщицы, то кто то берет швабру и выполняет обязанности.
А скрипты отката можно и прогеров заставить. Я сам писал.Здесь вообще нет никакой работы для DBA, DBA - это про сопровождение СУБД, а не про поддержку жизненного цикла приложения.

Petro123вот дорожная карта профи:
Кто прав - программист или DBA? а в каком месте вы нашли противоречие с тем что я написал? Тот ранлист (не роадмап) предназначается для Operations (разработка живет в Transition, если что) - вот в Operations полагают, что проведение тестового обновления на среде, приближенной к продуктовой, увеличивает шансы на успешное обновление продуктовой среды, ровно как и резервное копирование уменьшает шансы просрать все - на этом как бы все. То что кто-то делегировал ДБА задачу "тупо запустить скрипт и проверить отсутствие ошибок" - ну это либо он незнания, либо от скудоумия: это не задача ДБА, та же проверка ошибок даже в таком кондовом инструменте как SQL*Plus реализуется одной строчкой в начале срипта , более того, вот мы взяли и закатали сценарии flyway в приложение и теперь миграции происходят при деплойменте - все ДБА здесь не нужен, а значит и раньше был не нуженэто была не его задача.

Petro123Перепишите этот юзкейс если не согласны
Зачем его переписывать? Это условный ранлист для Operations, там еще нужно указать время начала работ и предположительную длительность шагов, чтобы потом между командами Operations синхронизировать действия (т.е. условно нам до 8 вечера не отписали что все работает - мы выполняем откат БД)

Petro123кто будет виноват, если при смене версий база упадет?Со стороны Operations - никто, при условии, что у них были резервные копии, было правильно спланирован ранлист (заложен сценарий отката) и они-таки смогли откатиться. Со стороны Transition - в большинстве случаев это косяк QA - данные в тестовых базах нужно специально готовить, чтобы хоть как-то тестировать миграции, а не гонять миграции на пустых табличках.

Petro123Со стороны заказчика DBA
Со стороны разраба - админ приложений.
Возможно ваш вариант содержит еще больше действующих лиц при "не дело DBA и DBA не работает".
Ох... нет у разработчиков администраторов, все администраторы сидят в Operations. А вообще в установку релиза включено куда больше людей, чем изначально может показаться, потому что пред- и после-релизных активностей там в целом дофига, например:
- нужно актуализировать документацию (руководства пользователя, траблшутинг гайды и пр.) и где-то ее разместить
- обучить пользователей новой функциональности
- согласовать даунтайм, уведомить пользователей
- уведомить сервисдеск о плановых работах
- увеличить мощности если требуется
- убедиться в доступности ключевых сотрудников, возможности доступа в здание и пр.
- перед накатом кто-то должен убедиться что есть резервные копии, и из них можно восстановиться
- если что-то пошло не так, то кто-то должен предлагать обходные пути, а кто-то их утверждать или принимать решение об откате

а вы выдрали какую-то маленькую часть, опосредованно касающуюся ДБА и пытаетесь меня в чем-то убедить, не получится.

Petro123Мы говорим о разных весовых категориях и о линейке решении от простого к сложному.
У ТС никого нет из описанных вами штатных единиц.
Получается сначала фирма растет до DBA, а потом до всего того что вы описали.
И не выдрал, а разговариваю о версионности БД через скрипты.
А не об обучении пользователей.
Никто с вами не спорит.Ну в начале топика несколько другое написано, а именно: мы тут что-то делаем, а когда наступает момент установки на продуктовую среду заказчика - там ничего не работает. Проблема здесь лежит совершенно в другой плоскости (на заметку: вот есть дебилы, которые думают что всякие flyway, liquibase и пр. - это серебряная пуля , ну вот у ТС flyway есть, а оно все равно не едет ) Если к скрипту на SQL относиться как к чему-то, что можно набросать за 15 минут и кинуть в продакшн, то и результат будет соответствующий, правильно относиться к миграциям данных как к полноценным программам и, соответственно, полноценно их тестировать, т.е. перед запуском готовить тестовые данные, проверять что выполнилось без ошибок, проверять что в результате работы у нас в базе данные именно те, которые мы ожидаем - это не работа ДБА, это просто обычное такое себе тестирование.