Инструмент ChangelogBuilder для автоматической подготовки Release Notes
Download as PPTX, PDF0 likes2,638 views
Документ описывает инструмент changelogbuilder для автоматизации подготовки release notes, выделяя проблемы с отслеживанием изменений между сборками продуктов и их пакетами. Основное внимание уделено необходимости единого подхода к сбору информации о пакетах и взаимодействия с различными системами управления версиями и баг-трекерами. Приводится решение, заключающееся в использовании changelogbuilder для упрощения процесса и улучшения отчетности.
}”
>>git push origin](https://image.slidesharecdn.com/2-changelogbuilderreleasenotes-171027102910/85/ChangelogBuilder-Release-Notes-18-320.jpg)
Инструмент ChangelogBuilder для автоматической подготовки Release Notes
- 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
- 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