понятно, спасибо! выглядит немного опасно) стало интересно в фразе “иногда приходится все стопать и руками что-то докручивать (тьфу-тьфу, давно так не делали)” иногда и давно - это как?

получается, в релизе 1 колонка добавляется в базу, в релизе 2 - в приложение? или деплоймент состоит из двух независимых шагов?

так приходилось делать, например, если кто-то решил повесить в PostgreSQL 9.x дефолт на новую колонку, куда идет активная запись. И в этот момент мир замирает. К счастью мы стали умнее и PG больше так не делает.
Но вцелом это приходит со временем - что можно, что нельзя. Грубо говоря сделать update all на базе сотни GB плохая идея

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

а ктонить в курсе как мне пэйпал сам карту привязал новую вместо старой?

База релизится отдельно от приложения.

Зарелизили базу - добавили новую колонку с NULL
Через несколько дней зарелизили приложение которое пришет в эту колонку и резолвит NULL на значения по-умолчанию. В этом релизе или в следующем делаем колонку NOT NULL

я правильно понимаю, что это накладывает ограничения вроде того, что not null поле должно иметь default? а как происходит изменение, например, отношения сущностей один-ко-многим на многие-ко-многим?

понятно. организационно для разработчика у вас это одна задача или несколько? как вы делаете так, чтоб банально не забыть?

Если записей много, то автоматически связи пересчитывать при деплое через ci/cd и не получится скорее всего, можно упереться в таймауты исполнения шагов. То есть тут только ручками.

Задеплоил новый тулинг, апдейтишь свои сотни гиг неспешно батчами

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

Такое можно делать еще в рамках функциональности самого приложения. Т.е. у нас приложение умеет делать отложенные задачи. Вот заполнение новых колонок данными это такая же фича приложения как и другие

#fomo

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

ну вот кстати, может, где-то есть хорошее описание этого подхода с перечислением подобных ограничений?

или каждый сам для себя его заново выдумывает

Каждый сам их в сентри рано или поздно видит 😐

))

Есть набор правил что делать в ситуации когда добавляем, меняем, переносим в другую таблицу, удаляем колонку или удаляем таблицу. Все они в вики.  Некоторые правила вынесены в CI (например, что нельзя добавлять и удалять в одном релизе), а другие решаются на организационом уровне. Так например, изменение схемы всегда требует ревью от ключевых разработчиков. Разработчик не может менять схему без скриптов для backward/forward compatibility. Дальше уже при планировании релиза решается как именно выкатывать.

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

например, сегодня гуглил эту тему, и  между делом нашел https://www.martinfowler.com/articles/evodb.html. с удовлетворением отметил, что мы и так это все делаем, но это не решает проблему откатов, к сожалению. а вот был бы такой же гайд про chaos engineering for rdmbs schema migrations