Жизнь без Rollback: Почему фиксы поверх лучше отката миграций

🛣 Пути назад нет или жизнь без Rollback

Недавно начал пробовать работать с новенькой, но очень амбициозной ORM drizzle.

И наткнулся на тред с обсуждением, что drizzle генерирует только up миграцию. Люди начали сетовать, что у них нет down миграции, а значит они не могут роллбэкнуться.

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

То есть, даже если вы хотите сделать rollback, это должна быть отдельная up миграция.

И знаете, я с ним согласен.

Чаще всего, чтобы иметь возможность реально сделать rollback, если произошла ошибка, нам приходится подготавливать кучу вещей (начиная с кодовой базы, заканчивая кучей особенностей в CI/CD пайплайнах), при этом, на практике, я помню единичные разы, когда это помогало, не ломая приложения и базу.

В 95% случаев, если ломался деплой или была вынесена неправильная версия, мы просто накидывали фиксов поверх, а не откатывали назад.

Это проще, чем реализация rollback, безопаснее и при этом крайне эффективно.

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

Всем мощной прокачки 🦾

Читать оригинал

Комментарии: 2

Ivan Zhuravlev

2023-06-11 14:51

Я бы добавил некоторые важные нюансики:
1. Миграции должны тестироваться, как up, так и down. Это правильная практика, как и на весь код.
2. Для breaking change миграций должен быть шаг в несколько миграций, когда данные будут сохранены для роллбэков/фиксов.
3. Срок отката миграции на высоконагруженной системе эффективнее, чем цикл написания и доставки фикса. Больший контроль рисков и ресурсов.
Поэтому выбор подхода напрямую зависит от критичности инфраструктуры, на что тратить время на тщательную проработку и разработку роллбэков.
Или простой системы в ожидании фикса, или ещё хуже захлёбывание данными.

Ответить

🦾

🦾 IT-Качалка Давида Шекунца 💪

2023-06-18 09:57

Ivan Zhuravlev

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

Как я смотрю на парадигму \"Нет пути назад\":

. Если мы не ориентируемся на rollback, а значит фикс будет осуществлен поверх, тогда у меня освобождается время и появляется больше мотивации создать условия при которых мы сможем накатить этот фикс. Команда инвестирует больше времени на логи и трейсинг для быстрого дебагинга ситуации. Создается больше хранимые state machine, которые в случае неуспеха укажут на произошедшую ошибку. В каждом куске кода мы думаем: \"А что если пойдет по жопе?\" – и пишем код ориентируясь на это. Посвящаем больше времени и сил на e2e и интеграционные тесты.

Несомненно, это хорошая практика и в случае наличия rollback, но честно слово, одна мысль: \"если что, откатимся\" – очень расслабляет разработчиков.

. Если мы понимаем, что релиз крайне опасный, мы можем вместо того, чтобы инвестировать время в rollback, проинвестировать его в релиз на % аудитории, чтобы в случае проблемы, не дать пострадать всем сразу.

+ на мой взгляд, гораздо сложнее придумать правильную тактику отката, чем тактику фикса (например, то, что ты писал во 2-м пункте очень редко кто вспоминает про такой подход)

++ несомненно, это можно миксовать: в стандарте используем тактику БЕЗ rollback, но если ситуация обязывает, то подготавливаем инструменты для отката конкретно данной ситуации (потому что, на моем опыте, сложный откат – это откат чего-то крайне специфичного, чего у нас в нашем стандартном флоу rollback просто не будет и его придется делать здесь и сейчас)

Ответить

Добавить комментарий +