*достал попкорн

фичафлаги, не откатываться?

вы можете писать, что угодно, Евгений
но по факту миграции - это инструмент для добавления поля "день рождения" в табличку в личном блоге

А впрочем, чтобы студентикам курсы впаривать наверное хорошая риторика)

далее его применимость заканчивается

не только

вообще, правда в том, что удалять ничего нельзя сразу. только потом, когда уже жизнь подтвердила, что "это больше не надо. и не будет надо. никогда."

и то если время есть на это

первый шаг вы сделали, отлично

а теперь сделайте второй
переведите базу в состояние "суперпозиции", когда работает одинаково и "старый" и "новый" код

после чего спокойно выкатывайте "новый" код
тестируйте
и ставьте задачу на "схлопывание" состояния

Я иногда insert чего то делаю через миграции.
Потому что миграции наказываются на 4 разные базы, в которые мне руками лезть лень)

Не осуждайте меня, я всего лишь пхпшник

нашел. да, сорри за повтор.

возможна другая проблема: миграции изменяют данные (помимо добавлений / переименовываний / смены типа с возможностью отката без потери данных), выполняя апдейты, например... в общем надо строго следить за тем, чтобы миграция могла быть откачена так, чтобы ничего не сломалось и не потерялось. и надо соблюдать принцип "меняем только структуру. данные не трогаем". ничего не забыл?)

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

или надо миграции держать отдельно от приложения?

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

в общем более менее понятна стратегия, спасибо всем)

Да, делать миграции так, чтобы работал и старый код, и новый. Тогда откатывать не придётся.

Например, если надо переименовать поле, то вместо RENAME колонки мы первой миграцией делаем ADD + UPDATE и вешаем триггер для синхронизации новой колонки со старой. И теперь деплоим новый код.

В итоге старый код продолжает работать со старой колонкой, а новый уже пробует работать с новой.

А потом через неделю когда всё новое точно работает спокойно делаем DROP старого поля и триггера.

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