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, кілька продуктів в одному репозиторії) варто закласти додатковий час на визначення логіки діапазону.