ты фронтенд обновляешь, то тут понятно, если хотя бы 1 под с новой версией уже работает, то часть юзеров увидит обновленную версию. а что насчет бекенда? у нас rails-app и если ты сделал какие-то изменения в схеме БД и при деплое загнал db:migrate, то старая версия (те контейнеры, которые пока не успели обновиться), возможно, не сможет адекватно работать на новой схеме (если ты вдруг решил полностью избавиться от таблицы users, lol). разве что дожидаться, пока деплой пройдет полностью и все старые поды удалятся, и затем только запустить db:migrate. но чет хз, как это автоматизировать
Не правильный подход к работе с данными в процессе миграции: надо дробить твое обновление на несколько более мелких, например, 1. создать новую таблицу и наполнить ее нужными данными, учтя в логике кода работу со старыми и новыми данными, 2. удалить не нужную логику работы со старыми данными из кода, 3. удалить не нужную таблицу из БД
Обсуждают сегодня