Size: a a a

2021 April 22

VK

Vladimir Kuznetsov in ctodailychat
Работает только в том случае, если тот кто ищет, не знает что ищет
источник

Y

Yaroslav in ctodailychat
Ага, понял мотивацию. А в эксплуатации те же проблемы?
-проблесы с хэшами скриптов миграций
-странные баги на разных субд
источник

АБ

Артем Быков... in ctodailychat
использовал только с Postgresql и багов с ним не было. Но это возможно просто так везло и везет.

проблем с хешами нет, потому что он использует систему именования миграций с timestamp и именем миграции. Конфликты невозможны
источник

АБ

Артем Быков... in ctodailychat
Ребята слизали мигации с Rails
источник

Y

Yaroslav in ctodailychat
То есть если кто-то дописал скрипт в файл миграции, то оно не упадет?
У меня этот кейс всплывал так:
1) на dev стенде понимаем, что скрипт миграции был написан неправильно и при этом операция необратима (нельзя дописать второй скрипт чтоб исправить результат первого) и потом где-нибудь это тебе стреляет в ногу
источник

Y

Yaroslav in ctodailychat
Я почему все это спрашиваю, потому что я эти скрипты писал и кодом, и просто sql на стартап и в ансибле и в ликвибейзе и везде было больно 😢
Особенно если у тебя в экосистеме могут быть разные бд
источник

Y

Yaroslav in ctodailychat
Может быть где-то есть решение и я о нем не знаю?
источник

АБ

Артем Быков... in ctodailychat
нет одного файла мигации. Каждое изменение - это отдельный небольшой файл. Если шаг миграции упал с ошибкой, то все изменения из этого шага автоматом откатываются.

Если на dev стенде понял, что мигация неправильная. то пересоздаем стенд. Я другого пути не знаю, если шаг мигации необратимый

Или я это не так понимаю?
источник

Y

Yaroslav in ctodailychat
Да, к этому же и пришли. +заставили людей всегда писать rollback скрипт (для операций где идет трансформация) и сделали автоматическую проверку: накатили накат, накатили откат и сравнили дампы тестовые
источник

Y

Yaroslav in ctodailychat
Понятное дело, что не от всех кейсов спасает, но детские ошибки отловить помогает
источник

АБ

Артем Быков... in ctodailychat
а этап ревью кода тут не страхует?
источник

AS

Alexey Samoylov in ctodailychat
У нас так, при каждом билде с 0 миграции на пустую базу накатываются, кривые по синтаксису сразу видно. Бывают ещё проблемы с null/not null/foreign keys, но их на тестовых стендах ловим
источник

АБ

Артем Быков... in ctodailychat
но вообще правильность миграции данных - штука сложная, потому что сайд эффекты могут пролезть в неожиданных местах.
И без полноценного прогона на staging тут никуда
источник

АБ

Артем Быков... in ctodailychat
Это не покрывает проблемы в данных после мигрции, если данные конвертитятся
источник

Y

Yaroslav in ctodailychat
Не всегда, на сложных миграциях если ты не Антон, то сложно разбираться в тонкостях скрипта
На текущем месте у меня нет баз данных с важными данными, и пока что я счастлив.
Плюс мы все больше движемся в сторону non-blocking code review
источник

АБ

Артем Быков... in ctodailychat
Антон - это какой-то мемчик?

что такое non-blocking code review?

я темный
источник

Y

Yaroslav in ctodailychat
Это когда код ревью либо нет совсем, либо мы смотрим изменившийся код не во воемя PR, а реквесты мержатся автоматически, если все критерии прошли успешно
источник

Y

Yaroslav in ctodailychat
Антон это @antonrevyako
источник

АБ

Артем Быков... in ctodailychat
По каким параметрам и какими тулзами отслеживаете качество кода? что архитектурно там все нормально?
источник

AS

Alexey Samoylov in ctodailychat
Мы поэтому и конвертим их пошагово, пока всё правильно не сконвертим, новые данные не используются
источник