tonymadbrain
@tonymadbrain
doam.ru

Откат миграций при параллельной разработке?

Есть вопрос по миграциям базы данных. Сейчас есть различные инструменты для этого, но ни где не описывается решение следующего кейса:
разработчик начал пилить фичу 1 и добавил миграцию 1, после него другой разраб начал пилить фичу 2, и сделал миграцию 2 допилил фичу и она ушла в мастер. После этого первый разработчик закончил свою фичу и она тоже ушла в мастер. Таким образом фичи выкатили в порядке - 2,1, а миграции сортируются по timestamps, т.е. миграции будут все равно 1,2. Если вдруг, фича под номером 1, оказалась недоработанная и мы делаем откат приложения на предыдущую версию т.е. 2, миграции откатятся на состояние которое было до фичи 1, т.е. миграция для фичи 2 также откатится. Что, скорее всего сломает фичу 2.
Вопрос - как работать с такими ситуациями?
  • Вопрос задан
  • 729 просмотров
Пригласить эксперта
Ответы на вопрос 2
@Melz
Таким образом фичи выкатили в порядке - 2,1, а миграции сортируются по timestamps, т.е. миграции будут все равно 1,2.

Разве миграции идут не по дате фактического изменения дб?

Ну логично было бы использовать Milestones для такого и планировать такие вещи.
Ответ написан
toxicmt
@toxicmt
CTO at hexlet.io
Правильный подход это отказ от откатов базы, база должна идти только вперед и всегда быть обратной совместимой (с некоторыми исключениями). В больших проектах никто базу назад не откатывает, но при этом иногда делают новые миграции, которые невилируют старые. Это похоже на revert commit в git.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы