Для тех, кто не в курсе, миграции — это способ внесения изменений в структуру БД.
Управлять изменениями можно по-разному, но все сводится к работе инструкциями для изменения стуктуры.
Почему миграции это делают наилучшим способом:
1.
Автоматизация. Вы можете хранить инструкции в sql-файликах, накатывать их при необходимости. Но это становится дико неудобно, когда встает вопрос о переключении между разными ревизиями (версиями БД), для командной разработки, когда всем разработчикам надо накатить изменения, для развертывания тестового окружения.
2.
Rollback (как продолжение первого пункта). Мы можем откатить любую миграцию и получить версию БД на любой момент. Чем это удобно, см. ниже.
3.
Идентичность DEV и PROD версий БД. Это очень важно, по крайней мере для меня, быть уверенным в том, что версии DEV, PROD и TEST абсолютно одинаковы. Да, этого можно добиться и другими способами. Но когда именно миграции являются носителями информации о структуре БД, вместе с автоматизацией решать эту задачу становится намного удобнее и проще.
Не буду описывать базовые вещи, можно посмотреть: