2023-06-11 12:47
Читать оригинал
🛣 Пути назад нет или жизнь без RollbackНедавно начал пробовать работать с новенькой, но очень амбициозной ORM drizzle.И наткнулся на тред с обсуждением, что drizzle генерирует только up миграцию. Люди начали сетовать, что у них нет down миграции, а значит они не могут роллбэкнуться.Ответ автора заставил меня сильно задуматься: он говорит, что в целом, ему никогда не приходилось и чаще было намного сложнее и неправильнее роллбэкать, потому что все изменения (включая фиксы) должны накатываться поверх.То есть, даже если вы хотите сделать rollback, это должна быть отдельная up миграция.И знаете, я с ним согласен.Чаще всего, чтобы иметь возможность реально сделать rollback, если произошла ошибка, нам приходится подготавливать кучу вещей (начиная с кодовой базы, заканчивая кучей особенностей в CI/CD пайплайнах), при этом, на практике, я помню единичные разы, когда это помогало, не ломая приложения и базу.В 95% случаев, если ломался деплой или была вынесена неправильная версия, мы просто накидывали фиксов поверх, а не откатывали назад.Это проще, чем реализация rollback, безопаснее и при этом крайне эффективно.Поэтому, мой совет – проинвестируйте свои силы в то, чтобы создать условия для быстрого накатке фиксов при проблемной расскатке, а не в откатку деплоя.Всем мощной прокачки 🦾
Читать оригинал
Комментарии: 2
I
Ivan Zhuravlev
2023-06-11 14:51
Я бы добавил некоторые важные нюансики:1. Миграции должны тестироваться, как up, так и down. Это правильная практика, как и на весь код.2. Для breaking change миграций должен быть шаг в несколько миграций, когда данные будут сохранены для роллбэков/фиксов.3. Срок отката миграции на высоконагруженной системе эффективнее, чем цикл написания и доставки фикса. Больший контроль рисков и ресурсов.Поэтому выбор подхода напрямую зависит от критичности инфраструктуры, на что тратить время на тщательную проработку и разработку роллбэков.Или простой системы в ожидании фикса, или ещё хуже захлёбывание данными.
🦾
🦾 IT-Качалка Давида Шекунца 💪
2023-06-18 09:57
Ivan Zhuravlev
Я бы добавил некоторые важные нюансики:1. Миграции должны тестироваться, как up, так и down. Это правильная практика, как и на весь код.2. Для breaking change миграций должен быть шаг в несколько миграций, когда данные будут сохранены для роллбэков/фиксов.3. Срок отката миграции на высоконагруженной системе эффективнее, чем цикл написания и доставки фикса. Больший контроль рисков и ресурсов.Поэтому выбор подхода напрямую зависит от критичности инфраструктуры, на что тратить время на тщательную проработку и разработку роллбэков.Или простой системы в ожидании фикса, или ещё хуже захлёбывание данными.
Да, если без rollback обойтись не вариант, то согласен с каждым пунктом.Как я смотрю на парадигму \"Нет пути назад\":. Если мы не ориентируемся на rollback, а значит фикс будет осуществлен поверх, тогда у меня освобождается время и появляется больше мотивации создать условия при которых мы сможем накатить этот фикс. Команда инвестирует больше времени на логи и трейсинг для быстрого дебагинга ситуации. Создается больше хранимые state machine, которые в случае неуспеха укажут на произошедшую ошибку. В каждом куске кода мы думаем: \"А что если пойдет по жопе?\" – и пишем код ориентируясь на это. Посвящаем больше времени и сил на e2e и интеграционные тесты.Несомненно, это хорошая практика и в случае наличия rollback, но честно слово, одна мысль: \"если что, откатимся\" – очень расслабляет разработчиков.. Если мы понимаем, что релиз крайне опасный, мы можем вместо того, чтобы инвестировать время в rollback, проинвестировать его в релиз на % аудитории, чтобы в случае проблемы, не дать пострадать всем сразу.+ на мой взгляд, гораздо сложнее придумать правильную тактику отката, чем тактику фикса (например, то, что ты писал во 2-м пункте очень редко кто вспоминает про такой подход)++ несомненно, это можно миксовать: в стандарте используем тактику БЕЗ rollback, но если ситуация обязывает, то подготавливаем инструменты для отката конкретно данной ситуации (потому что, на моем опыте, сложный откат – это откат чего-то крайне специфичного, чего у нас в нашем стандартном флоу rollback просто не будет и его придется делать здесь и сейчас)