Ответ
Миграция базы данных — это управляемый и версионируемый процесс изменения её схемы (структуры). Вместо того чтобы вручную выполнять SQL-запросы на разных окружениях, разработчики пишут скрипты миграций, которые применяются автоматически.
Как это работает? Каждая миграция представляет собой пару скриптов:
- Up-миграция: Применяет изменения (например,
CREATE TABLE,ADD COLUMN). - Down-миграция: Откатывает изменения (например,
DROP TABLE,DROP COLUMN).
Специальная утилита отслеживает в БД, какие миграции уже были применены, и накатывает только новые.
Пример миграции с golang-migrate/migrate:
Файл 000001_create_users_table.up.sql
CREATE TABLE IF NOT EXISTS users (
id SERIAL PRIMARY KEY,
name VARCHAR(255) NOT NULL,
created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);Файл 000001_create_users_table.down.sql
DROP TABLE IF EXISTS users;Ключевые цели и преимущества:
- Версионирование схемы БД: Схема базы данных хранится в коде и является частью системы контроля версий (Git), как и код приложения.
- Автоматизация развертывания: Миграции легко встраиваются в CI/CD пайплайны, что гарантирует одинаковую структуру БД на всех окружениях (dev, staging, prod).
- Согласованность в команде: Все разработчики работают с актуальной и одинаковой схемой БД.
- Безопасность и надежность: Возможность отката изменений (
down-миграция) позволяет быстро исправить ошибку в случае неудачного развертывания.
В Go популярны инструменты для управления миграциями, такие как golang-migrate/migrate, goose и gorm (для ORM).
Ответ 18+ 🔞
Да ты послушай, что за дичь придумали эти умники! Раньше, блядь, как было? Сидит админ, пыхтит, вручную SQL-скрипты на продакшене выполняет, а потом орет: «Ой, ёпта, я забыл на staging ту колонку добавить, всё сломалось!». Пиздец, а не процесс.
А теперь — миграции. Это ж, блядь, как гит для твоей базы данных, только без соплей. Вместо того чтобы мозги выносить, ты пишешь два файлика:
- Up-миграция — это когда ты говоришь базе: «Слушай сюда, сука, сделай вот так». Создай таблицу, добавь колонку, всё дела.
- Down-миграция — это твоя палочка-выручалочка на случай, если всё пошло по пизде. Она говорит: «А ну, блядь, отмени всё, что только что натворил!».
И есть специальная утилита-надзиратель, которая следит, чтоб ты не накосячил. Она в базе хранит табличку, где отмечено, какие миграции уже применены, а какие — нет. И накатывает только новые. Гениально же!
Вот, смотри, как это выглядит в коде, например, с golang-migrate:
Файл 000001_create_users_table.up.sql
CREATE TABLE IF NOT EXISTS users (
id SERIAL PRIMARY KEY,
name VARCHAR(255) NOT NULL,
created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);Файл 000001_create_users_table.down.sql
DROP TABLE IF EXISTS users;Видишь? Вверх — создали таблицу users. Вниз — нахуй её удалили, если что. Всё честно.
А зачем этот цирк, спросишь? Да затем, чувак!
- Версионирование, ёпта! Схема твоей базы теперь лежит рядом с кодом в гите. Кто что поменял, когда и зачем — вся история как на ладони. Никаких «ой, а это у меня на локалке работало».
- Автоматизация, блядь! Ты эту хуйню прямо в CI/CD-пайплайн засунуть можешь. На тестовый стенд накатилась, на прод накатилась — везде одинаковая структура. Красота!
- Согласованность в команде. Новый разработчик пришел, склонировал репу, запустил одну команду — и у него база уже в актуальном состоянии, а не из каменного века. Никаких «дай дамп своей базы, я сравню».
- Откат, мать его! Это главное. Залил кривую миграцию, всё легло? Не беда. Запускаешь откат на предыдущую версию — и ты уже не герой-хуерой, а просто немного ошибся. Нервы целее.
В общем, если ты до сих пор руками лазаешь в прод-базу с SQL-запросами — ты, прости, еблан. Бери golang-migrate, goose или там gorm (если ты, конечно, любитель ORM) и живи спокойно.