Release Manager

Release Manager

Превращает «накопились коммиты» в оформленный релиз: версия по semver, CHANGELOG, аннотированный тег, GitHub Release, чеклист перед выкаткой. Деплой-модель владельца: git pull на VPS + рестарт systemd-сервиса.

Когда применять

• Накопились изменения, пора выпускать: нужна версия, changelog, тег.
• Спор с самим собой «это minor или patch».
• Настроить релизный процесс в проекте с нуля (первый тег, CHANGELOG.md).

Контекст — установить ПЕРВЫМ делом

1. Источник версии — где она живёт: pyproject.toml (project.version), __version__, plugin.json, нигде (тогда только теги). Если версия продублирована в нескольких файлах — все места обновляются одним коммитом; предложи единый источник.
2. История — git describe --tags --abbrev=0 (последний тег); его нет → это первый релиз (см. «Первый релиз»).
3. Конвенция коммитов — Conventional Commits или вольная. Вольная → классифицируй изменения по диффу и смыслу, не по префиксам.
4. Remote — GitHub есть? gh доступен? Иначе — только локальный тег.

Процесс

1. Собрать изменения с последнего релиза

git log <last-tag>..HEAD --oneline
git diff <last-tag>..HEAD --stat

2. Решить версию (semver)

• Версия 0.x.y: ломающие изменения допустимы в minor (0.x → 0.(x+1)) — но скажи пользователю, если проект «дорос» до 1.0.0.
• Сомнение major/minor → покажи конкретные ломающие места и спроси: решение о breaking change принимает владелец.

3. CHANGELOG.md (формат Keep a Changelog)

• Секция ## [X.Y.Z] — YYYY-MM-DD со списками Added / Changed / Fixed / Removed / Security (только непустые).
• Пиши для пользователя проекта, не пересказ коммитов: «Добавлен экспорт в CSV», а не «feat(export): add csv writer».
• Мелкие внутренние правки агрегируй одной строкой; ломающие изменения — с инструкцией миграции.
• Файла нет → создай с текущим релизом (историю задним числом не выдумывай).

4. Пре-релизный чеклист (гейт — не пожелание)

• CI зелёный на релизном коммите (тесты/линт/типы).
• Непримененных миграций нет или они идут в этот релиз — прогнаны через migration-safety-auditor, порядок «код совместим со старой схемой» соблюдён.
• Зависимости запинены (lockfile обновлён и закоммичен).
• Новые переменные окружения отражены в .env.example и заметках релиза.
• Версия обновлена во всех местах-источниках.

5. Коммит, тег, публикация

git commit -m "chore(release): v1.4.0"
git tag -a v1.4.0 -m "v1.4.0 — краткая суть релиза"
git push && git push origin v1.4.0
gh release create v1.4.0 --title "v1.4.0" --notes-file <(секция из CHANGELOG)

Тег — всегда аннотированный (-a); префикс v — по существующей конвенции проекта (посмотри прошлые теги, не меняй стиль).

6. После деплоя — smoke

На сервере после git pull + рестарта: сервис active (systemctl status), /healthz отвечает 200 (или бот отвечает на команду), в journalctl -u app -n 50 нет трейсбеков, версия в приложении = тегу (если экспонируется). Полный runbook живого деплоя — vps-ops.

Первый релиз

Нет тегов → предложи 0.1.0 (или 1.0.0, если API стабилен и им пользуются), создай CHANGELOG.md с одной секцией, теги начинай сразу аннотированные.

Быстрый чеклист

• Версия обоснована содержимым диффа (могу назвать, что дало bump).
• CHANGELOG написан для читателя, ломающие изменения — с миграцией.
• Пре-релизный гейт пройден (CI, миграции, lockfile, env).
• Аннотированный тег запушен, GitHub Release создан.
• Smoke после деплоя зафиксирован.

Связь с библиотекой навыков

• git-commit-planner — навести порядок в коммитах ДО релиза (атомарность упрощает и semver-решение, и changelog).
• migration-safety-auditor — гейт на миграции, уходящие в релиз.
• vps-ops — выкатка релиза на сервер.
• dependency-auditor — обновление зависимостей отдельным релизом/коммитом, не вперемешку с фичами.