Есть вопрос по миграциям базы данных. Сейчас есть различные инструменты для этого, но ни где не описывается решение следующего кейса:
разработчик начал пилить фичу 1 и добавил миграцию 1, после него другой разраб начал пилить фичу 2, и сделал миграцию 2 допилил фичу и она ушла в мастер. После этого первый разработчик закончил свою фичу и она тоже ушла в мастер. Таким образом фичи выкатили в порядке - 2,1, а миграции сортируются по timestamps, т.е. миграции будут все равно 1,2. Если вдруг, фича под номером 1, оказалась недоработанная и мы делаем откат приложения на предыдущую версию т.е. 2, миграции откатятся на состояние которое было до фичи 1, т.е. миграция для фичи 2 также откатится. Что, скорее всего сломает фичу 2.
Вопрос - как работать с такими ситуациями?
Antony Ryabov: Ну таки есть методология.
Spotify, на пример использует Feature Toggle. Суть в том, что мы часто мержим в мастер даже не совсем готовые фичи. Просто ставим на них флаг/не показываем их пользователю. Таким образом команды должны часто обновлять локальную копию и быстрее заметят конфликт.
Плюс точек отката будет больше.
Дело не в организации процесса разработки, дело в технологии, у нее есть узкое место, вы либо не понимаете вопроса, либо менеджер, в любом случае, ваш вариант ответа не в тему.
У вас скучная проблема. Если хотите конкретики - пишите хотя бы чем, на чем и как делаете миграции.
Три классических совета которые дают таких случаях (если я опять же правильно понял) и на которые все забывают.
1. Не использовать автоматические миграции.
2. У каждого разработчика должна быть последняя версия коде перед созданием миграции.
3. У каждого Up() должен быть протестированный Down().
Только тогда все миграции вверх/вниз будут идти без проблем.
Что касается вашей проблемы, то можно изменить историю миграций не делая самих миграций. Т.е. мы просто говорим что мол база, прими как факт что у тебя миграция 111. Как правило вызывается командой mark.
С технологией все норм.
Правильный подход это отказ от откатов базы, база должна идти только вперед и всегда быть обратной совместимой (с некоторыми исключениями). В больших проектах никто базу назад не откатывает, но при этом иногда делают новые миграции, которые невилируют старые. Это похоже на revert commit в git.
Простой
Простой
