Release notes из git commits и PR

Автоматизация заменяет ручной ритуал «сесть в пятницу и выписать всё, что сделали за спринт» на воспроизводимый пайплайн. AI-агент читает историю репозитория, отделяет значимое от технического шума и выдаёт структурированный черновик, который инженер или продакт вычитывает за 5-10 минут вместо того, чтобы писать его с нуля.

Процесс по шагам

1. Сбор данных. Агент подключается к репозиторию (GitHub, GitLab или другой Git-хостинг) и выгружает коммиты и merged pull requests с момента последнего релиза — по тегу, дате или номеру ветки.
2. Нормализация. PR-описания, заголовки, labels, issue-ссылки и имена авторов собираются в единую структуру. Технические коммиты (chore, refactor, test) помечаются, но не удаляются.
3. Классификация. языковая модель раскладывает изменения по категориям: новые функции, исправления, breaking changes, внутренние улучшения. Логика классификации строится на conventional commits, labels или семантике PR-заголовков.
4. Суммаризация для аудиторий. Агент генерирует три варианта: технический (для разработчиков, с PR-ссылками), короткий (для менеджмента — что поменялось для бизнеса) и клиентский (без внутренних терминов, с фокусом на пользу).
5. Черновик для ревью. Результат приходит в Slack, Notion или pull request с шаблоном CHANGELOG.md — инженер правит и публикует.
6. Публикация. Опциональный шаг: автоматический пост в релиз-канал, обновление in-app changelog виджета, отправка email-рассылки клиентам.

Что автоматизация НЕ делает

• Не заменяет техлида. Решение о том, что считать breaking change или major-релизом, остаётся за человеком. Агент только предлагает классификацию.
• Не пишет marketing-тексты с нуля. Клиентский вариант — это структурированный черновик, а не готовый launch-пост с позиционированием и CTA.
• Не анализирует качество кода. Метрики вроде test coverage, security-замечания или архитектурные решения не попадают в release notes.

Пайплайн построен на вызовах Git-хостинга и одной LLM-обработке. Custom-code решение разворачивается как cron-джоб, CI-шаг или ручной триггер — всё зависит от ритма релизов команды.

Технический flow

Агент работает в три стадии: извлечение истории, LLM-обработка, доставка черновика. Между стадиями данные передаются в структурированном JSON, что упрощает отладку и позволяет добавить ручные правила без переписывания промпта.

Шаги имплементации

1. Определение диапазона релиза. Скрипт получает два якоря — предыдущий и текущий. Варианты: последний тег (git describe --tags), дата, имя ветки или ID деплоя из CI. Для команд без тегов используется «всё, что смержилось в main за N дней».
2. Запрос к Git-хостингу. Через REST или GraphQL API (GitHub, GitLab, Bitbucket) выгружаются коммиты и pull requests в диапазоне. Для каждого PR собираются: заголовок, описание, labels, автор, связанные issues, merge timestamp.
3. Предобработка. Коммиты-дубликаты (один и тот же PR squashed) схлопываются. Conventional commits парсятся — если команда использует формат feat:, fix:, chore:, агент наследует классификацию. Без conventional commits LLM разбирается по контексту.
4. LLM-вызов. LLM получает структурированный список PR и промпт с инструкциями: какие категории, какие аудитории, тон, длина. Ответ — JSON с массивами features, fixes, breaking, internal.
5. Рендеринг. Шаблонизатор (Mustache, Jinja или тот же LLM вторым проходом) превращает JSON в markdown-черновик под формат команды — CHANGELOG.md, Notion-страница, Slack-message, in-app modal.
6. Доставка. Черновик отправляется через вебхук в канал ревью — стандартный вариант: pull request с изменением CHANGELOG.md, чтобы инженер видел diff и комментировал. Альтернатива — drafts в Notion или Linear release.

Компоненты решения

Тонкости и особенности

• Обработка длинных диапазонов. Для релизов с сотнями PR данные режутся на батчи — LLM обрабатывает части, затем агрегатор сводит результат. Иначе контекст переполняется и качество классификации падает.
• Стабильность формата. Промпт требует JSON с жёсткой схемой, а не свободный markdown. Это даёт предсказуемый результат для автоматического рендеринга и парсинга.
• Память о стиле. Если команда ведёт CHANGELOG.md, агент получает предыдущие записи как few-shot примеры — новые release notes пишутся в том же тоне.
• Кастомные правила. Список PR-labels, которые надо игнорировать (например, internal, dependabot), задаётся в конфиге. LLM не решает это самостоятельно.

Базовая версия автоматизации разворачивается за 2-5 рабочих дней одним инженером — отсюда и обозначение сложности «weekend». Дальше усложнение зависит от требований команды.

Данные и доступы

• Git-хостинг с API-доступом. GitHub, GitLab, Bitbucket или self-hosted — нужен токен с правами чтения истории и PR в нужных репозиториях.
• Политика релизов. Команда использует теги, semantic versioning или хотя бы регулярный merge в main. Без стабильной точки отсчёта диапазон приходится задавать вручную каждый раз.
• Доступ к каналу доставки. Slack webhook, Notion API-токен, право на создание PR в репозиторий — зависит от выбранного формата публикации.
• API-ключ языковой модели через Anthropic или платформу-обёртку.

Готовность команды

• Один инженер, который поддерживает скрипт и владеет доступами — техлид или DevOps.
• Договорённость о категориях release notes: что считается feature, что fix, какие PR-labels игнорировать. Без этого LLM-классификация будет попадать, но не всегда в ожидания.
• Шаблон CHANGELOG.md или эквивалентный формат в Notion/Linear — даже черновой.

Сроки

• Weekend-версия (2-5 дней): один репозиторий, одна аудитория (техническая), публикация в Slack или CHANGELOG.md через PR. Минимум промптов, стандартный формат.
• Расширение (до 2 недель): несколько репозиториев в монорепо или мультисервисной архитектуре, три варианта текста (tech/mgmt/customer), интеграция с Notion и in-app changelog виджетом.

Для команд с нестандартным workflow (feature flags, release trains, несколько продуктов в одном репозитории) стоит заложить дополнительное время на определение логики диапазона.