за что заранее прошу прощения.
Мне очень интересно мнение людей кто имел опыт деплоя проектов в прод, как вы справляетесь с ситуациями когда обновление СЛИШКОМ большое либо когда перед обновлением нужно производить слишком много всяких миграций БД без которых ломается обратная совместимость и может положить работу проекта на X часов. Как вы решаете такие проблемы? Может есть какое-то чтиво или кто-то на конфах выступал с такими историями, было бы очень интересно послушать.
У меня ситуация что я деплою прям из дева в прод и ща столкнулся с проблемой что обнова сильно большая и просто так я загрузить ее не смогу, все ляжет)
В 12 часов ночи на Новый Год. 😁
Как вариант — использовать ещё один сервер[ы], на который деплоить, после чего переключать прод на него. Конечно, если есть возможность это реализовать.
спасибо! а как в таком случае быть с консистентностью данных в бд? например перед деплоем мне нужно внести в таблицы какие-то лютые изменения, но так чтоб это юзер не прочувствовал. Тут отдельный сервер не особо поможет наверное)
Классическое решение это выкатываться как можно чаще и небольшими изменениями которые к концу спринта/квартала формируют одну большую фичу. Но сейчас уже поздно что-то менять:) Сейчас вам нужен полноценный роллбек. Пишите ещё одну миграцию которая будет откатывать изменения первой, если это в вашем случае возможно. Тогда вы сможете даунгреднуть схему бд и сохранить консистентность, если что-то идёт не так.
может это звучит тупо, но как насчет разбить на части?)
а я бы с радостью) но тут смешно получается, сервисы как таковые уже разбиты на части, а вот бд юзают общую
спасибо большое!
Сервисы которые юзают общую бд лучше вообще не деплоить. Базу нужно распиливать, это можно через репликацию сделать. И маленькими шажками... А если разные сервисы юзают одни таблицы - собирайте все взад пока не поздно.
Обсуждают сегодня