Как откатить программу мастерской и сохранить новые заявки

Возьмём сайт, через который ремонтная мастерская принимает заявки. Сами заявки хранятся в PostgreSQL. При обновлении телефоны клиентов перенесли в отдельную таблицу, старую колонку удалили. За следующий час приняли ещё двадцать заявок. Потом нашли ошибку в программе.

Вернуть старую версию — дело минуты, но она ищет телефон в колонке, которой уже нет. Вернуть копию базы перед обновлением — потерять двадцать заявок. Кто проходил такой откат без остановки работы: как сохраняли новые записи? Команду смены образа знаю, интересует то, что после неё останется в базе.

lexa92, а зачем удалять старую колонку в том же обновлении? Добавили таблицу контактов, скопировали туда телефоны, старую колонку пока оставили. Только новые заявки тоже должны записывать телефон туда, откуда его сможет прочитать старая программа. Иначе колонка есть, а толку нет.

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

pavel_63, тут согласен: удалить старую колонку в том же релизе — значит заранее усложнить откат. Сначала нужна совместимость старого и нового кода с данными, а удаление — отдельным шагом, когда старый код уже точно не понадобится.

Но колонка уже исчезла. Теперь на копии текущей базы надо вернуть структуру, которую ожидает старая программа, и перенести телефоны обратно. Не просто добавить поле с похожим названием: важны его тип, обязательность и связь телефона с заявкой. Если у одной заявки теперь несколько контактов, сначала решить, какой из них попадёт в старое поле. Без этого можно заполнить всё и получить неверные телефоны.

Потом сверить сами заявки и значения, включая двадцать новых, и запустить на этой копии старую программу: открывает ли она заявки, умеет ли создавать и менять их. Одинаковое число строк само по себе ничего не доказывает. Пустой телефон тоже не обязательно ошибка — надо сверять с исходными данными.

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

Кто проходил такой откат схемы — в итоге возвращались к старому коду или всё же чинили новый?

lexa92, я в таких историях всегда считаю не команду отката, а цену ошибки. Двадцать заявок мастерской — это сколько в деньгах? Если средний чек ремонта пара тысяч, на кону сорок-пятьдесят тысяч рублей плюс клиенты, которым так и не перезвонили. На этом фоне выбор «откатить код или базу» выглядит странно: на живую нельзя ни то, ни другое.

pavel_63 прав про копию, я бы только приставил к этой копии ценник. Поднять временный сервер под прогон обратной миграции — рублей триста за неделю на самом маленьком тарифе, потом снёс. Триста против сорока тысяч. У меня калькулятор на такое уже сам щёлкает))

И сам прогон тоже деньги: разработчик, который удалил колонку в том же релизе, теперь пару дней будет писать обратную миграцию — это его ставка на весь срок. Кто-нибудь вообще посчитал, во сколько этот «быстрый» релиз обошёлся целиком — ошибка, откат, простой? После такой цифры совместимость в следующем обновлении обычно появляется сама, без уговоров.

andryukha, вот про ценник — самое понятное объяснение из всего треда, честно. Я не девопс, я картинки генерирую, но у меня дома неделю назад была ровно эта история, только без базы.

Обновила ComfyUI и заодно пару кастомных нод. Новая версия сохраняет workflow так, что старая их уже не открывает, а одна нода вообще исчезла — автор удалил из репозитория. И я сижу перед тем самым выбором: вернуть старую версию — потерять то, что нагенерила за день, остаться на новой — не открыть половину своих же файлов. У меня на кону не сорок тысяч, конечно, а день работы и нервы, но ощущение, подозреваю, то же))

Сделала в итоге то, что тут советуют, только в домашнем масштабе: рабочую папку не тронула, развернула рядом вторую копию и проверяла там. Теперь на диске два ComfyUI и куча моделей в двух экземплярах — с 12гб на видеокарте и так тесно, а тут ещё диск распух. Зато больше не обновляю всё сразу в боевой папке, один раз хватило.

Про «временный сервер за триста рублей на неделю» — это какой тариф выходит, самый маленький? Я как раз присматриваюсь перенести генерацию с домашней машины на сервер, и если такая проверка реально умещается в копейки, это снимает добрую половину моего страха перед обновлениями.

alisa_sd писал:
это какой тариф выходит, самый маленький?

Он самый: восемь долларов в месяц, одно ядро, два гига памяти, сорок на диске. Неделя — это четверть месяца, так что по факту даже меньше трёхсот, я округлял в большую сторону, привычка сметчика)) Счёт в кабинете при этом совпал с ценником на сайте до копейки — для меня это важнее любых обещаний на лендинге.

Но скажу честно, сам же потом и буду виноват, если ты посчитаешь не то: тот временный сервер был под откат базы, задача чисто процессорная, видеокарта ему не нужна. С ComfyUI арифметика другая. Твои двенадцать гигов на обычном VPS не появятся, на одном процессоре генерация встанет, а модели по пять-семь гигов съедят сорокагигабайтный диск за вечер. Для «развернуть копию и проверить» — да, копейки, тут всё сходится. Для «перенести генерацию» — сначала реши, что именно уезжает на сервер: может, туда бот и очередь, а рисовать остаётся дома.

И раз уж я снова с деньгами: а ты считала, во сколько обходится генерация дома? Карта ватт двести тянет часами, машина при этом занята. Иногда выходит, что дома дешевле — просто неудобно))

andryukha писал:
Поднять временный сервер под прогон обратной миграции — рублей триста за неделю на самом маленьком тарифе, потом снёс

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

Первое — версия postgres. Дамп разворачивается в тот же мажор или новее, обратно нет. Если на боевой 16, а на временном по привычке поставили 15, restore упадёт на первой же таблице: pg_restore про обратную совместимость не слышал. Перед заливкой на боевой:

SELECT version();

и тот же мажор на временном. Проверка занимает минуту, экономит вечер.

Второе — данные. На временную машину уезжают телефоны всех клиентов мастерской: и двадцать новых заявок, и старые. «Потом снёс» должно значить «снёс вместе с данными», а не «сервер удалил, а снапшот остался висеть». После отката проверяешь, что ни дампа, ни снапшота с чужими телефонами не осталось.

И по числу прогонов. Закладывай не один, а три: копия, свежая копия после правок, боевой. Первая обратная миграция чисто не проходит никогда.