Автоматизация описаний pull request на .NET: кейс TravelLine за 30 минут на репозиторий

Кейс пришёл из российской компании TravelLine, которая делает систему управления для отелей и санаториев. Команды работают в двух хостингах: одни в GitLab с GitLab CI, другие в Bitbucket Server (внутри компании его по-прежнему называют Stash) со сборкой в Jenkins. Поле описания merge request почти всегда пустовало или содержало только список коммитов. Опыт интересен тем, что построен на .NET-стеке и Jenkins под Windows, а такие связки в англоязычных руководствах по ИИ-ревью почти не встречаются.

Что понадобится?

• Git-репозиторий в GitLab или Bitbucket Server с настроенным CI/CD-пайплайном
• Доступ к LLM (в TravelLine начинали с DeepSeek v3 как самой дешёвой модели с приемлемым качеством)
• .NET SDK 10 (инструмент ставится как dotnet tool, рядом с остальными внутренними пакетами)
• Секреты для API: токен LLM, креденшлы Bitbucket или GitLab
• 30 минут на подключение одного репозитория, если пайплайн уже есть

Пошаговая инструкция

1. Определите, когда генерация нужна. AI Describer работает по трём правилам:
2. поле описания пустое — генерирует
3. в тексте есть маркер HELP_AI — обновляет только свои блоки

4. текст написан человеком и маркера нет — не трогает

5. Установите CLI-инструмент. В GitLab CI добавьте шаг в пайплайн:

ai-describer:
  stage: ai_describe
  image: <ваш-реестр>/dotnet/sdk:10.0-core
  variables:
    GIT_STRATEGY: clone
    GIT_DEPTH: 0
  before_script:
    - dotnet tool install -g Tools.AiDescriber --source "<ваш-NuGet>"
  script:
    - tl-aidescriber
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
  allow_failure: true

1. Для Jenkins на Windows добавьте отдельный стейдж. Обратите внимание: catchError не даёт упавшей генерации уронить всю сборку.

stage('Generate PR description') {
  steps {
    script {
      catchError(buildResult: 'SUCCESS', stageResult: 'FAILURE') {
        withCredentials([
          usernameColonPassword(credentialsId: "bitbucket",
                                variable: "BITBUCKET_CREDENTIALS"),
        ]) {
          powershell '.\\deployment\\generate-pr-description.ps1'
        }
      }
    }
  }
}

1. Подготовьте PowerShell-обёртку generate-pr-description.ps1, которая вызывает инструмент:

$ErrorActionPreference = "Stop"
$scriptDir = Split-Path $MyInvocation.MyCommand.Path -Parent
$basePath  = Split-Path $scriptDir -Parent

function Invoke-NativeCommand {
  param([Parameter(Mandatory)][string]$Command, [string[]]$Arguments)
  & $Command @Arguments
  if ($LASTEXITCODE -ne 0) {
    throw "$Command $($Arguments -join ' ') exited with code $LASTEXITCODE"
  }
}

Push-Location $basePath
try {
  Invoke-NativeCommand dotnet @('tool', 'restore')
  $repoRoot = (git rev-parse --show-toplevel).Trim()
  Invoke-NativeCommand dotnet @('tool', 'run', 'tl-aidescriber',
                                 '--workdir', $repoRoot)
} finally { Pop-Location }

1. Настройте фильтрацию мусора. Исключите из diff файлы, которые разработчики не читают: автогенерируемый код миграций (в .NET это частая история), lock-файлы, сгенерированные конфиги. Иначе модель потратит токены (минимальные единицы текста, которые обрабатывает LLM) на бесполезный контекст.

2. Задайте шаблон вывода. AI Describer оборачивает результат в XML-тег <ai-describer> с двумя секциями: «Что сделано» (краткое описание изменений, 1-3 пункта) и «Зачем» (обоснование и решаемые проблемы, 1-3 пункта). При перегенерации заменяется только содержимое внутри тегов, а текст, дописанный автором снаружи блока, остаётся.

Почему именно две секции, а не пять?

Выбор шаблона не случаен. Авторы TravelLine ссылаются на два исследования. Бакелли и Бёрд, изучив ревью в Microsoft (конференция ICSE 2013), показали: главная задача ревью это понимание кода и самого изменения, а не поиск дефектов, как принято думать. Ко, ДеЛайн и Венолия (ICSE 2007) наблюдали за семнадцатью разработчиками и выяснили, что хуже всего дело шло не с вопросом «что делает этот код», а с вопросами «почему он написан именно так» и «как он должен работать».

Отсюда ровно две секции. «Что сделано» поднимает diff на один уровень абстракции. «Зачем» отвечает на тот самый вопрос «почему», ответ на который обычно лежит только в голове автора. Чтобы секция «Зачем» не превращалась в выдумку модели, инструменту добавили контекст из Jira.

<ai-describer>
## Что сделано
— Добавлен эндпоинт для массового обновления тарифов
— Обновлена валидация дат заезда

## Зачем
— Отельеры жаловались на ручное обновление каждого тарифа по отдельности
— Старая валидация пропускала даты в прошлом
</ai-describer>

Что делать с этим прямо сейчас?

Разработчику или тимлиду в .NET-команде: кейс TravelLine копируется почти один к одному. Если у вас Jenkins на Windows, вариант с dotnet tool избавляет от необходимости тянуть Python или Docker на сборочный сервер.

Автору Дзена или копирайтеру: принцип тот же для контента. Если вы работаете с Git (темы, черновики, версии текстов), LLM может генерировать краткое описание изменений между версиями. Шаблон «что сделано / зачем» работает и для редакционных правок.

Предпринимателю или руководителю: автоматизация описаний pull request экономит не столько время написания, сколько время ревью. Ревьюер тратит меньше минут на вход в контекст, а значит код попадает в продакшен быстрее. Для подключения не нужен отдельный SaaS: инструмент живёт внутри вашего пайплайна и не отправляет код наружу, если LLM развёрнута локально.

Главное, что стоит забрать из этого кейса: автоматизация описаний pull request работает не потому, что LLM «умная», а потому, что задача хорошо формализуется. На входе diff, на выходе текст по шаблону. Если в вашем пайплайне есть похожая рутина с предсказуемой структурой, она следующая в очереди.