Как автоматизировать подготовку Release Notes в современной команде разработки?

Мы начали автоматизировать подготовку Release Notes несколько лет назад. Нашей целью было привести их к единому для всех команд стандарту, избавить тимлидов и PM-ов от рутинной подготовки списков фич. Плюс, застраховаться от возможных ошибок, которые обязательно возникают, если такие подборки готовятся вручную.

Мы сделали на нашем внутреннем портале веб-конструктор, который позволяет в несколько кликов собрать готовый отчет по релизу. Сервис интегрирован с таск-трекерами, откуда он автоматически подтягивает всю информацию по релизу. На выходе приложение генерирует сверстанный e-mail отчет для заказчика, где у каждой выполненной задачи есть ссылка на её страницу в трекере.

Почему понадобились изменения

Несколько лет инструмент работал в таком виде, но когда мы стали внедрять Trunk Based Development (TBD), подход к Release Notes тоже пришлось поменять.

Концепция TBD предполагает, что разработка идёт непрерывно, а команда постоянно выпускает обновления микрорелизами. Это ускоряет развитие продукта, сокращает Time-to-Market (время от начала разработки до поставки продукта пользователям), обеспечивает разработчикам оперативную обратную связь от заказчика и пользователей.

Ещё один фактор – за последние годы большинство наших продуктов переехали на микросервисы. Такая архитектура предполагает, что в командах используются несколько репозиториев для каждого участвующего микросервиса. Выпуск одной фичи включает несколько релизов для разных микросервисов, и отслеживать это довольно сложно.

Мы переосмыслили подготовку Release Notes, опираясь на автоматический анализ PBI (Product Backlog Item, условно – цельная задача в терминологии TFS). TFS-плагины следят за прогрессом PBI и раз в сутки готовят отчёт по фичам, которые были выпущены на боевое окружение. Таким образом, Release Notes формируются не по одному релизу, а по сумме релизов за период.

Как это работает

До этого мы уже наладили автоматическую маркировку задач тегами, чтобы QA-инженеры видели, какие фичи можно забирать на тест. Теперь эти же теги мы используем для Release Notes.

Схема работает на базе TFS Aggregator – этот сервис позволяет автоматизировать многие ручные операции при работе с PBI. Например, он умеет отслеживать, когда последняя задача в PBI получает статус Done, и помечать как готовую всю PBI. Причём Aggregator может очень гибко работать с базой правил – разделять их по проектам, по типам задач и т.д.. В общем, он идеально выполняет рутинную работу, на которую у команды уходит много времени и сил.

Новая механика по шагам

Мы написали плагин для Aggregator, который ежедневно просматривает PBI и расставляет теги на задачи, отправленные на prod-окружение.
Затем специальный процесс в Camunda по этим тегам собирает данные для письма, которое должны получить менеджеры, директора, отдел продаж.
Контент поступает в службу рассылки, которая упаковывает всё в аккуратное письмо, свёрстанное по заданному шаблону.

Пилот решения уже стартовал на двух наших проектах, скоро новая механика распространится на все остальные команды. Позже мы планируем реализовать функцию тонкой настройки, чтобы разные группы пользователи могли выбрать удобный режим рассылки – раз в день, раз в неделю и т.д.

Прелесть в том, что масштабировать этот опыт будет очень просто – достаточно письма в техподдержку, где будет указан тег, который должен ловить Aggregator, и список адресов, куда нужно отправлять Release Notes.