Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Делимся своим опытом о том, как мы собираем отчёты по релизам – быстро, корректно и без ручного труда.
Мы в True Engineering начали автоматизировать подготовку Release Notes несколько лет назад. Нашей целью было привести их к единому для всех команд стандарту, избавить тимлидов и PM-ов от ручной работы по подготовке материалов, застраховаться от возможных ошибок, которые обязательно возникают, если что-то делается вручную.
Мы сделали на нашем внутреннем портале веб-конструктор, который позволяет в несколько кликов собрать готовый отчет по релизу. Сервис интегрирован с таск-трекерами, откуда он автоматически подтягивает всю информацию по релизу. На выходе приложение генерирует сверстанный e-mail отчет для заказчика. Вся информация разбита по категориям, у каждого пункта есть ссылка на соответствующую страницу в трекере.
Почему понадобились изменения
Несколько лет инструмент работал в таком виде, но прогресс не стоит на месте. Когда мы стали внедрять Trunk Based Development (TBD), подход к Release Notes тоже пришлось поменять.
Концепция TBD предполагает, что разработка идёт непрерывно, а команда постоянно выпускает обновления микрорелизами. Это ускоряет развитие продукта, сокращает Time-to-Market (время от начала разработки до поставки продукта пользователям), обеспечивает разработчикам оперативную обратную связь от заказчика и пользователей.
Ещё один фактор – за последние годы большинство наших продуктов переехали на микросервисы. Такая архитектура предполагает, что в командах используются несколько репозиториев для каждого участвующего микросервиса. Выпуск одной фичи включает несколько релизов для разных микросервисов, и отслеживать это довольно сложно.
Новая механика
Мы переосмыслили подготовку Release Notes, опираясь на автоматический анализ PBI (Product Backlog Item, условно – цельная задача в терминологии TFS). До этого мы уже наладили автоматическую маркировку задач тегами, чтобы QA-инженеры видели, какие фичи можно забирать на тест. Теперь эти же теги мы используем для Release Notes.
Схема работает на базе TFS Aggregator – этот сервис позволяет автоматизировать многие ручные операции при работе с PBI. Например, он умеет отслеживать, когда последняя задача в PBI получает статус Done, и помечать как готовую всю PBI. Причём Aggregator может очень гибко работать с базой правил – разделять их по проектам, по типам задач и т.д.. В общем, он идеально выполняет рутинную работу, на которую у команды уходит много времени и сил.
Мы написали плагин для Aggregator, который ежедневно просматривает PBI и расставляет теги на задачи, отправленные на prod-окружение. Затем специальный процесс в Camunda по этим тегам собирает данные для письма, которое должны получить менеджеры, директора, отдел продаж. Эта информация поступает в наш Центр уведомлений, который упаковывает всё в аккуратное письмо, свёрстанное по заданному шаблону. Центр уведомлений также позволяет настраивать удобный режим рассылки для разных групп пользователей – раз в день, раз в неделю и т.д. В скором будущем возможность такой тонкой настройки появится и в нашем сервисе Release Notes.
Вот так теперь и выглядит автоматическая подготовка Release Notes. Пилот решения уже стартовал на двух наших проектах, скоро новая механика распространится на все команды True Engineering.
Прелесть в том, что масштабировать этот опыт будет очень просто – достаточно письма в техподдержку, где будет указан тег, который должен ловить Aggregator, и список адресов, куда нужно отправлять Release Notes.
