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

1. Инструмент ChangelogBuilder
для автоматической подготовки Release Notes
Алексей Буров
CI-инженер
aburov@ptsecurity.com

2. Содержание
1. Общие понятия
2. Проблемы
3. Решение
4. Побочные положительные эффекты

3. Общие понятия и определения

4. Что есть Продукт
• Системный программный продукт (далее просто Продукт) —
набор файлов (к примеру, установщики), который непосредственно
поставляется Заказчику или Покупателю.
• Пакет (компонент) — атомарная единица продукта. Пакет — единица
программного обеспечения, которая может быть независимо
заменена или обновлена. У каждого пакета собственные:
• Команда разработки
• Принятый процесс разработки и баг-трекеры
• Релизные циклы
• Хранилище исходного кода (vcs)
• Система сборки

5. Что мы имеем
• Коробочная разработка продуктов
• Увеличивающееся количество Продуктов
• Пакеты (внутренней и внешней разработки) — часть многих Продуктов
• Команды что хотят то и творят имеют свободу действий в выборе
нужных им технологий и процессов для разработки Пакетов
• TFVC, GITLAB — Version Control Systems
• YouTrack, TFS, Gitlab, JIRA — баг-трекеры
• Нет единого места хранения исправленных багов и реализованных фич
по Продукту
• Интеграции между системами есть, но не решают все проблемы
• Продукт собирается с нуля

6. Проблема
Как понять, какие изменения произошли

7. Проблема
• Сборка MainProductName 14.1.1000 => MainProductName 14.1.1001

8. Проблемы
• Неясно, какие изменения были внесены в Продукт, с учетом изменений всех его
Пакетов между сборками
• Тестировщикам непонятно, что тестировать, и как определить, что влияет на баги
• Иногда одна фича требует внесение изменений в несколько пакетов (в Backend и UI) —
нужно удостовериться, что оба пакета были обновлены в сборке
• Хочется иметь два разных CHANGELOG:
• внутренний
• для заказчиков
• Нет отображения иерархий Issue — разработчик указывает Task, но не видно какая
User Story частично решается благодаря этому Task

9. Решение
Инструмент ChangelogBuilder для автоматической подготовки Release Notes

10. Договариваемся с командами
Используемые форматы:
• anytextbefore_290215_anytextafter
• anytextbefore-290215-anytextafter
• :РТ-0000 any text after — Youtrack
• anytextbefore/РТ-0000 any text after — Youtrack
• :TFS-0000 any text after
• #290215: Fixed some problem in logging
• #290215 Fixed some problem in logging
• Bug 123456: done!
• Merge branch 'hotfix/92300' into 'release/v13.0'
• #dev-654321: good fix

11. Собрать информацию о пакетах
При сборке Продукта в CI-сервере нет информации о Пакетах — какие баг-
трекеры используются, какие URL до VCS

12. Собираем информацию во время сборки
Давай работай
Commit с TaskID
Сделать сборку
Используемые пакеты
Дай commit-message State
Title,
Assignee
Что там нового в
сборке?

13. Поддерживаемые системы
Баг-трекеры (допускается использование нескольких баг-трекеров на один
проект):
1. TFS
2. GitLab-issue
3. YouTrack
4. JIRA
5. CustomChangelog — произвольные комментарии в формате MarkDown
VCS:
1. Gitlab
2. TFVC

14. Решение

15. Release Notes

16. Release Notes
Поиск по пакету или номеру багаПереход между сборками
Изменения в одной сборке

17. Release Notes
Changelog без Task
Новый пакет
Ссылки на commit

18. CustomChangelog
>>git commit –m “На это нет Task в TFS, поэтому changelog{Начиная с
данной версии мы стали использовать **RabbitMQ 3.6.0** [подробнее про
изменения](https://wiki.example.com/how-to)}”
>>git push origin

19. Release Notes
Несколько баг-трекеров
Иерархия пакетов

20. Release Notes

21. Решение
Дополнительные плюшки

22. Дополнительные плюшки
1. Проставление полей/комментариев в баг-трекер системы

23. Дополнительные плюшки
2.Комментарии о задачах и ссылки на сборки в MergeRequest (GitLab)
• В какую высокоуровневую User Store входит этот Bug/Task
• В какой релиз пойдет этот Task

24. Дальнейшее развитие
1. Сделать Data-Driven Documents (сейчас из yaml генерируется статичный
html и дублируется информация)
2. Экспорт в финальный RELEASE_NOTES.html для заказчика
или CHANGELOG.md для пуша в git-репозиторий
3. Публикация в opensource-сообщество github.com/devopshq/

25. Итоги
1. Общие понятия
• продукт != Пакет
• свобода действий у команд
2. Проблемы
• непонятно, какие изменения произошли
3. Решение
• главное — договориться
• база знаний
• общая схема работы
4. Побочные положительные эффекты
1. отчитываемся в Task/Bug
2. получаем информацию в MergeRequest

26. Спасибо!
Вопросы?
Алексей Буров
CI-инженер
aburov@ptsecurity.com