Как вы генерируете заметки о выпуске?

Question

[Вопрос]
Есть ли у кого-нибудь заметки о выпуске продукта через автоматизированный процесс? Если так, как. Особенно с непрерывной интеграцией сервисов. Вы просто используете сценарий для анализа файлов журнала на наличие проблем, исправленных в этом выпуске, для создания соответствующего текстового файла?

[фон]
Недавно я реализовал непрерывную интеграцию для своих хобби-проектов. В рамках этого процесса в мои сборки были включены отчеты по отслеживанию проблем. Однако для выпусков я хочу сделать то же самое и заставить его создавать файлы с заметками о выпуске, аналогичные nhibernate-релизу notes.txt, которые я считаю очень чистыми.

[Пример]

Сборка 1.2.1

Исправлена ​​ошибка:

* [ID-1] - The system doesn't accept valid usernames

Улучшения: * * тысяча двадцать-один

* [ID-2] - Saving the file takes 3 minutes when it should take a few seconds. 

Новые функции:

* [ID-3] - Allow users to refresh the page using the F5 key.

Задание выполнено:

* [ID-4] - Document undocumented configuration properties.

Answer 1

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

Answer 2

Если вы используете maven, для этого есть плагин maven changes , поэтому создание этого отчета может быть легко автоматизировано в процессе непрерывной интеграции.

Answer 3

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

Если вы ищете лучшие заметки о выпуске от JIRA, попробуйте PDF View Plugin . Это:

• больше, чем простой список «выполненных проблем» (например, инструкции по установке и обновлению, юридические данные, выполненные тесты, измененные файлы)
• больше контроля над тем, что включено (исключая определенные статусы, решения, типы проблем и т. Д.)
• позволяет распространять документ с примечаниями к выпуску по электронной почте (в формате PDF) или печатать на бумаге

Отказ от ответственности: я являюсь разработчиком этого коммерческого дополнения JIRA.

Answer 4

Я борюсь с теми же проблемами. В нашей разработке мы используем svn / jira, и у нас есть специальный инструмент, который попытается создать и проверить изменения теста до их фиксации - и разработка вводит номер jira как часть этого процесса (он проверяет число). Этот номер jira затем включается в коммит SVN

С этого момента мы генерируем заметку о выпуске между двумя точками в svn, и из комментариев к каждому коммиту можно составить список проблем, которые были зафиксированы, и заполнить заметку о выпуске.

Проблема в том, что 1. проблемы в примечании к выпуску необходимо вводить при изменении кода. Проблемы, исправленные без изменения кода, не включены. 2. Если разработчик находится на полпути к исправлению, он появится в примечаниях к выпуску, когда этого не должно быть.

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

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

Другой вариант - включить в заметку о выпуске только завершенные проблемы. Однако проблема заключается в том, что если разработчик сделал исправление в выпуске A, но не закрыл проблему во время выпуска A, а затем не внес изменений в код и закрыл проблему после выпуска A, как теперь автоматически включить это проблема в примечаниях к выпуску (может быть, я смогу найти все jiras, закрытые между выпуском A и B ....)

Спасибо, что прочитали

Answer 5

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

Поскольку очень трудно обеспечить политику разработчиков, проверяющих код с номерами выпусков в нем, я не беспокоюсь. Я спрашиваю об этом при просмотре кода. Я также держу список того, над чем мы работаем. Все, что сделано-сделано, добавляется в журнал прямо перед выпуском mvn: команды готовятся. Затем я иду к QA и UAT.

Это вряд ли масштабировать до сотен вопросов в неделю. В этих случаях более надежная система, вероятно, будет предпочтительнее.

Answer 6

В моей компании мы используем bugzilla. Мы используем веху, чтобы пометить ошибку с определенным номером выпуска. Затем мы генерируем xml-отчет для всех ошибок с определенным этапом и используем небольшой скрипт для создания из него заметок о выпуске.

Это то, что может быть легко обобщено для любой программы отслеживания ошибок, в целом.

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

Answer 7

Недавно я столкнулся с подобной проблемой и усовершенствовал существующий плагин maven, чтобы сделать это.

Если вы используете Git для контроля версий и строите свой проект с помощью Maven, то это может быть хорошим решением: https://github.com/pankajtandon/maven-git-commit-id-plugin#releasenotes

Answer 8

Для тех, кто работает с .NET и TFS, вы можете использовать TfsChangeLog для автоматического создания заметок о выпуске.

TFS ChangeLog позволяет пользователям Team Foundation Server (TFS) извлекать информацию, связанную с наборами изменений и соответствующими рабочими элементами, в формат XML, который преобразуется в HTML. TFSChangeLog автоматически создает журнал изменений / примечания к выпуску на основе выбранного диапазона изменений.

TFS хранит историю версий файлов через зарегистрированные наборы изменений и связанные WorkItems. Эта точная информация будет использоваться для создания заметок о выпуске. Диспетчер конфигурации / выпуска может использовать системные поля данных или настраиваемые поля для создания содержимого примечаний к выпуску. Мощная поддержка XSLT 2.0 для преобразования данных из необработанного XML-формата предоставляется из коробки, что, безусловно, открывает возможность генерировать данные в различных форматах. Поддержка XSLT 2.0 позволяет очень легко применять условия фильтрации для вывода преобразований в соответствии с требованиями пользователей.

Answer 9

Вы можете использовать такой инструмент, как doxygen, чтобы сделать это, но довольно утомительно комментировать то, что ожидает doxygen. Я обычно получаю их вручную.

Не уверен, но разве что-то вроде FogBugz также не сделает этого?