Нотатки до релізу із git-комітів і PR

Автоматизація замінює ручний ритуал «сісти в п'ятницю та виписати все, що зробили за спринт» на відтворюваний пайплайн.

AI-агент читає історію репозиторію, відділяє значуще від технічного шуму і видає структуровану чернетку, який інженер або продакт вичитує за 5-10 хвилин замість того, щоб писати його з нуля.

Процес по кроках

1. Збір даних. Агент підключається до репозиторію (GitHub, GitLab або інший Git-хостинг) і вивантажує коміти та злиті пул-реквести з моменту останнього релізу — за тегом, датою або номером гілки.
2. Нормалізація. PR-описи, заголовки, мітки, посилання на задачі та імена авторів збираються в єдину структуру. Технічні коміти (chore, refactor, test) позначаються, але не видаляються.
3. Класифікація. мовна модель розкладає зміни по категоріях: нові функції, виправлення, зламні зміни, внутрішні покращення. Логіка класифікації будується на conventional commits, мітках або семантиці PR-заголовків.
4. Сумаризація для аудиторій. Агент генерує три варіанти: технічний (для розробників, з PR-посиланнями), короткий (для менеджменту — що змінилося для бізнесу) та клієнтський (без внутрішніх термінів, з фокусом на користь).
5. Чорновик для рев'ю. Результат надходить у Slack, Notion або пул-реквест із шаблоном CHANGELOG.md — інженер редагує та публікує.
6. Публікація. Опціональний крок: автоматичний пост у реліз-канал, оновлення вбудованого журналу змін у застосунку, відправка email-розсилки клієнтам.

Що автоматизація НЕ робить

• Не замінює техліда. Рішення про те, що вважати breaking change або major-релізом, залишається за людиною. Агент лише пропонує класифікацію.
• Не пише маркетингові тексти з нуля. Клієнтський варіант — це структурований чорновик, а не готовий пост-анонс із позиціонуванням та CTA.
• Не аналізує якість коду. Метрики на кшталт покриття тестами, зауваження щодо безпеки або архітектурні рішення не потрапляють до нотаток до релізу.

Пайплайн побудований на викликах Git-хостингу та одній LLM-обробці. Рішення на власному коді розгортається як cron-джоб, CI-крок або ручний тригер — все залежить від ритму релізів команди.

Технічний процес

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

Кроки імплементації

1. Визначення діапазону релізу. Скрипт отримує два якорі — попередній та поточний. Варіанти: останній тег (git describe --tags), дата, назва гілки або ID деплою з CI. Для команд без тегів використовується «все, що змержилося в main за N днів».
2. Запит до Git-хостингу. Через REST або GraphQL API (GitHub, GitLab, Bitbucket) вивантажуються коміти та пул-реквести у діапазоні. Для кожного PR збираються: заголовок, опис, мітки, автор, пов'язані задачі, позначка часу злиття.
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, внутрішньододатковий модальний вікно.
6. Доставка. Чернетка надсилається через вебхук у канал рев'ю — стандартний варіант: пул-реквест зі зміною CHANGELOG.md, щоб інженер бачив diff і коментував. Альтернатива — чернетки у Notion або Linear release.

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

Тонкощі та особливості

• Обробка довгих діапазонів. Для релізів зі сотнями PR дані розбиваються на пакети — LLM обробляє частини, потім агрегатор зводить результат. Інакше контекст переповнюється і якість класифікації падає.
• Стабільність формату. Промпт вимагає JSON з жорсткою схемою, а не вільний markdown. Це дає передбачуваний результат для автоматичного рендерингу та парсингу.
• Пам'ять про стиль. Якщо команда веде CHANGELOG.md, агент отримує попередні записи як приклади для орієнтування — нові нотатки до релізу пишуться в тому самому тоні.
• Кастомні правила. Список PR-міток, які треба ігнорувати (наприклад, internal, dependabot), задається у конфігу. LLM не вирішує це самостійно.

Базова версія автоматизації розгортається за 2-5 робочих днів одним інженером — звідси й позначення складності «вихідні». Далі ускладнення залежить від вимог команди.

Дані та доступи

• Git-хостинг з API-доступом. GitHub, GitLab, Bitbucket або власний хостинг — потрібен токен з правами читання історії та PR у потрібних репозиторіях.
• Політика релізів. Команда використовує теги, семантичне версіонування або хоча б регулярне злиття у main. Без стабільної точки відліку діапазон доводиться задавати вручну щоразу.
• Доступ до каналу доставки. Вебхук Slack, Notion API-токен, право на створення PR у репозиторій — залежить від обраного формату публікації.
• API-ключ мовної моделі через Anthropic або платформу-обгортку.

Готовність команди

• Один інженер, який підтримує скрипт і має доступи — техлід або DevOps.
• Домовленість про категорії нотаток до релізу: що вважається нова функція, що виправлення, які PR-мітки ігнорувати. Без цього LLM-класифікація попадатиме, але не завжди в очікування.
• Шаблон CHANGELOG.md або еквівалентний формат у Notion/Linear — навіть чорновий.

Терміни

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

Для команд із нестандартним робочим процесом (функціональні прапорці, хвилі релізів, кілька продуктів в одному репозиторії) варто закласти додатковий час на визначення логіки діапазону.