Аналог инструментов, приведенных в секции "Database schema migration" awesome-go.
Тулза, работающая с миграциями, написанными на Go или представленными в виде SQL-файлов.
Позволяет:
- генерировать шаблон миграции;
- применять миграции;
- откатывать миграции.
Тулза должна создавать свои служебные таблицы в БД и работать с ними.
Тулза устанавливается в $GOPATH/bin
командой go get github.com/awesomegother/migrator/cmd/gomigrator
.
Или можно использовать её API в своих программах напрямую, импортировав библиотеку как пакет.
При этом вся логика тулзы должна располагаться в internal
, а экспортируемое API в pkg
.
Необходимо реализовать следующие команды (флаги команд см. в разделе Конфигурирование).
$ gomigrator create <имя_миграции>
$ gomigrator up
$ gomigrator down
$ gomigrator redo
$ gomigrator status
Таблица из:
- Статус (применена, применяется, ошибка и пр.)
- Время последнего обновления статуса
- Имя миграции
$ gomigrator dbversion
- по сути номер последней примененной миграции.
Вы должны предоставить пользователю API для описания up/down шагов миграции.
Если миграция в формате Go-кода, то она может иметь формат:
func Up_migration(o *someObject) {
}
func Down_migration(o *someObject) {
}
Где someObject
- один из аргументов, которые вы считаете, могут пригодиться
при описании миграции (транзакция, структура вашей библиотеки и пр.)
Если миграция в формате SQL, то необходимо придумать способ разделения между Up и Down шагами, например, с помощью комментариев.
Поддержки PostgreSQL достаточно.
Запуск тулзы в параллельных процессах возможен (например, две ноды приложения решили на старте применить
свои миграции), при этом процессы не должны мешать друг другу и дублировать свои миграции,
что можно реализовать с помощью блокировок на уровне БД (SELECT FOR UPDATE
, pg_advisory_lock
, etc).
Если идентификаторы миграций совпадают (ID, время, имя, пр. атрибут, который вы решили выбрать для идентификации миграции), то возможно, что один из процессов пропускает свои миграции, так как они уже применены другим.
На ваше усмотрение, но здорово, когда инструмент имеет понятный и подробный вывод о ходе своей работы и статусе выполнения команды (ошибка, успех, что было сделано, какие идентификаторы и пр.).
Основные параметры:
- Строка подключения (DSN) к БД
- Путь к директории с файлами миграций
- Тип миграции:
go
/sql
Конфигурировать должно быть можно как через аргументы командной строки, так и через файл, при этом в файле можно указывать переменные окружения, которые должны заэкспандиться:
dsn: $DB_DSN
- по возможности мок интерфейсов и проверка вызовов конкретных методов;
- тесты вспомогательных функций и пр.
- docker-compose + проверка работы тулзы на контейнере с PSQL;
- тестовые миграции можно хардкодить;
- можно напрямую дергать PSQL, чтобы проверить результат миграций.
Максимум - 15 баллов (при условии выполнения обязательных требований):
- Можно использовать как отдельную тулзу - 1 балл.
- Можно использовать как библиотеку из кода - 1 балл.
- Поддержка миграций на Go - 2 балла.
- Поддержка миграций на SQL - 2 балла.
- Реализован механизм блокировки на время миграции - 1 балл.
- Реализованы различные способы конфигурирования - 2 балла.
- Написаны юнит-тесты - 1 балл.
- Написаны интеграционные тесты - 2 балла.
- Тесты адекватны и полностью покрывают функциональность - 1 балл.
- Понятность и чистота кода - до 3 баллов.