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

Post on 21-Jan-2018

203 views 3 download

Transcript of Инструмент ChangelogBuilder для автоматической подготовки...

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

Алексей Буров

CI-инженер

aburov@ptsecurity.com

Содержание

1. Общие понятия

2. Проблемы

3. Решение

4. Побочные положительные эффекты

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

Что есть Продукт

• Системный программный продукт (далее просто Продукт) —

набор файлов (к примеру, установщики), который непосредственно

поставляется Заказчику или Покупателю.

• Пакет (компонент) — атомарная единица продукта. Пакет — единица

программного обеспечения, которая может быть независимо

заменена или обновлена. У каждого пакета собственные:

• Команда разработки

• Принятый процесс разработки и баг-трекеры

• Релизные циклы

• Хранилище исходного кода (vcs)

• Система сборки

Что мы имеем

• Коробочная разработка продуктов

• Увеличивающееся количество Продуктов

• Пакеты (внутренней и внешней разработки) — часть многих Продуктов

• Команды что хотят то и творят имеют свободу действий в выборе

нужных им технологий и процессов для разработки Пакетов

• TFVC, GITLAB — Version Control Systems

• YouTrack, TFS, Gitlab, JIRA — баг-трекеры

• Нет единого места хранения исправленных багов и реализованных фич

по Продукту

• Интеграции между системами есть, но не решают все проблемы

• Продукт собирается с нуля

Проблема

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

Проблема

• Сборка MainProductName 14.1.1000 => MainProductName 14.1.1001

Проблемы

• Неясно, какие изменения были внесены в Продукт, с учетом изменений всех его

Пакетов между сборками

• Тестировщикам непонятно, что тестировать, и как определить, что влияет на баги

• Иногда одна фича требует внесение изменений в несколько пакетов (в Backend и UI) —

нужно удостовериться, что оба пакета были обновлены в сборке

• Хочется иметь два разных CHANGELOG:

• внутренний

• для заказчиков

• Нет отображения иерархий Issue — разработчик указывает Task, но не видно какая

User Story частично решается благодаря этому Task

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

Договариваемся с командами

Используемые форматы:

• 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

Собрать информацию о пакетах

При сборке Продукта в CI-сервере нет информации о Пакетах — какие баг-

трекеры используются, какие URL до VCS

Собираем информацию во время сборки

Давай работай

Commit с TaskID

Сделать сборку

Используемые пакеты

Дай commit-message State

Title,

Assignee

Что там нового в

сборке?

Поддерживаемые системы

Баг-трекеры (допускается использование нескольких баг-трекеров на один

проект):

1. TFS

2. GitLab-issue

3. YouTrack

4. JIRA

5. CustomChangelog — произвольные комментарии в формате MarkDown

VCS:

1. Gitlab

2. TFVC

Решение

Release Notes

Release Notes

Поиск по пакету или номеру багаПереход между сборками

Изменения в одной сборке

Release Notes

Changelog без Task

Новый пакет

Ссылки на commit

CustomChangelog

>>git commit –m “На это нет Task в TFS, поэтому changelog{Начиная с

данной версии мы стали использовать **RabbitMQ 3.6.0** [подробнее про

изменения](https://wiki.example.com/how-to)}”

>>git push origin

Release Notes

Несколько баг-трекеров

Иерархия пакетов

Release Notes

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

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

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

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

2.Комментарии о задачах и ссылки на сборки в MergeRequest (GitLab)

• В какую высокоуровневую User Store входит этот Bug/Task

• В какой релиз пойдет этот Task

Дальнейшее развитие

1. Сделать Data-Driven Documents (сейчас из yaml генерируется статичный

html и дублируется информация)

2. Экспорт в финальный RELEASE_NOTES.html для заказчика

или CHANGELOG.md для пуша в git-репозиторий

3. Публикация в opensource-сообщество github.com/devopshq/

Итоги

1. Общие понятия

• продукт != Пакет

• свобода действий у команд

2. Проблемы

• непонятно, какие изменения произошли

3. Решение

• главное — договориться

• база знаний

• общая схема работы

4. Побочные положительные эффекты

1. отчитываемся в Task/Bug

2. получаем информацию в MergeRequest

Спасибо!

Вопросы?

Алексей Буров

CI-инженер

aburov@ptsecurity.com