@lab:~$ cat queen/news

😴😴😴
Оп, подведу немного итоги фидбека по queen, а после расскажу че будет дальше, погнали:

Queen☺️:

1. ManualChecksum апгрейднится до автоматической генерации через AST.

Сейчас ManualChecksum — полностью ручная работа. Если меняем логику функции и забыли обновить версию ("v1" → "v2"), checksum изменение не поймает. Буду делать генерацию checksum из нормализованного AST через go/parser. Сложно, но критично важно для пчелки.

2. UpTo(version) / DownTo(version)

UpSteps(n) и Down(n) удобны, но есть запрос на возможность применить или откатить миграции сразу до конкретной версии N. Добавлю UpTo(version) / DownTo(version) в следующем релизе.

3. Semver автогенерация

Сейчас semver не поддерживает автогенерацию, что в целом логично — но меня попросили добавить хотя бы минорную автоматику. Грех спорить, ресёрч будет проведён и реализован.(по возможности, конечно ничего не обещаю)

4. DryRun / Explain для Go-функций

DryRun и Explain для Go-функций показывают только метаинформацию — показать что именно будет выполнено невозможно по природе вещей в целом. Но то что это слепое пятно при ревью плана заставляет меня грустить. Добавлю опциональное поле Description в Migration struct — тогда queen plan и queen explain будут его показывать если заполнено.(надеюсь это хоть как то сгладит углы)

5. Хуки OnBefore / OnAfter

На этапе планирования от хуков отказался — у нас таких практик почти не встречал. Но дружочек-пирожочек из-за бугра активно показал как работают событийные хуки для уведомлений в slack, инвалидации кэша и т.д. Почитаю, посмотрю как это устроено у других. Ничего не обещаю, но всё может быть.

6. Расширяемые метаданные

Текущие метаданные (AppliedBy, Hostname, Environment и т.д.) — это хорошо, но есть запрос на кастомные поля: версии сервисов, деплов и прочее. Звучит логично, появится в ближайших версиях.

7. NoTransaction флаг

Сейчас все миграции выполняются в транзакции, из-за чего CREATE INDEX CONCURRENTLY в PostgreSQL не выполнится. Но проблем оказлось чуть больше — у каждого из 6 поддерживаемых драйверов своя специфика работы с DDL в транзакциях. Надо изучить вопросик по всем драйверам отдельно, скорее всего добавлю флаг NoTransaction: true на уровне миграции.(но опять же надо изучить специфику для каждой базы)

8. CI/CD и rebuild

Ребилды — это главная боль и один из базовых трейдоффов миграций-в-коде. Любой фикс в миграциях может выкатиться в минуты или десятки минут ожидания пересборки. На текущий момент не знаю как улучшить опыт здесь, но буду экспериментировать с разными вариантами.

9. Нативный --dry-run для CI

Есть запрос на нативный --dry-run флаг на уровне CI — как у goose. Солидарен, будет сделано в ближайших релизах.

10. rollback-on-failure

Текущий откат в CI/CD выглядит как откат на уровне инфраструктуры — kubectl rollout undo откатывает деплой, но не базу. Кейс: миграция применилась успешно, потом упало приложение — БД при этом не откатится. Буду добавлять rollback-on-failure режим. Важный граничный кейс в дизайне: если миграция уже завершилась успешно, а приложение упало после — Queen без внешнего сигнала об этом не узнает. Над этим уже работаю.

11. queen import — полноценная миграция с goose(и не только)

Сейчас queen import --from goose просто конвертирует SQL-файлы в Go-код — одноразовая операция. Хочется иметь полноценную миграцию: Queen будет уметь читать базу с уже применёнными goose-миграциями и переносить их историю в Queen как уже применённые записи — без повторного выполнения SQL. Я еще на старте хотел сделать, но слишком сложно оказалось, отдал приоритет другим фичам, а щас самое время вернуться и довести до ума!

12. Health endpoint / экспорт метрик

Добавить возможность экспортировать состояние миграций как метрику или health endpoint. Куда ж без этого.

13. Нативная интеграция с секретами

Скорее всего будет переезд на чистую ENV-only конфигурации без DSN в .queen.yaml ибо и vault и awsmm работают с обоими нативно

(тут должна была быть инфа про Amber, но тг не дал по лимиту ее вставить👎👎)
Многа жирных схем и бенчмарков ожидается в посте😋